1

Re: ViEmu 3.0 timeline

I was wondering if there is some sort of preliminary timeline for the next major release of ViEmu. I am really looking forward to having some sort of scripting capabilities.

Also, is there any preliminary information about said language? For instance, would it be possible to be able to call into Visual Studio VB?

2

Re: ViEmu 3.0 timeline

Hi Tomas,

Please take this as orientative rather than definitive. ViEmu/VS 3.0 is planned for after the summer, a couple of major features are mostly ready but a few other ones aren't (including the scripting).

I'm currently considering the different options for the scripting. One options is to use a custom-built language for which I designed and implemented a parser & VM, which is mostly a subset of Javascript. The other option I'm considering is embedding Python. From either of them, it should be possible to call external VS macros, which use VBA.

I'll be happy to hear other people's thoughts on this.

Regards,

  - Jon

3

Re: ViEmu 3.0 timeline

[accidental double post deleted]

Last edited by tomlu (2008-05-23 18:01:52)

4

Re: ViEmu 3.0 timeline

Good to hear it is in the works!

Personally, if there is no particular advantage using your custom language, I would go for embedding python. Python is well-tested, powerful, integrated with gvim, and last but not least people already know it.

Examples of things that I would like to do with scripting:

* Create a class/header combination using a custom template file as a vim command.
* Implement fuzzy project file open / tab selection as in ido.el for emacs
* Implement a shortcut replace-current-word-in-file command (can't find a good way to do this in vim)

Keep up the good work!

5

Re: ViEmu 3.0 timeline

tomlu, the advantage of a custom language is that I will have much more control over how it works, over making it available in different apps, etc... I still have to think about the various issues before reaching a decision.

Can you explain the examples you list above in more detail? I have some questions:

* Do you mean fully creating the header and class files, inserting them in the project, etc?

* What does ido.el do? I'd guess it matches substrings in filenames in any char position, does it do anything else?

* You mean something like this:

nnoremap <key> "zyiw:%s/\\<<c-r>z\\>//g<left><left>

but more "sophisticated"? I've tested this to work in ViEmu, although it should also work in vim.

Regards,

  - Jon

6

Re: ViEmu 3.0 timeline

I am sure whatever decision you reach will be fine.

* Yes, doing all of that. I am fine with calling out to python or whatever scripts that can manually parse and change the vcproj file.

* ido.el does fuzzy matching on the file structure. You get to see a list of the possible matches at all times so you can stop once the match is specific enough. You can go in and out of directories. There is a vim script that works well and does the same, it's called fuzzy something. It matches buffers as well as files. Highly recommended!

* That remap works well, thanks!

7

Re: ViEmu 3.0 timeline

admin wrote:

I'm currently considering the different options for the scripting. One options is to use a custom-built language for which I designed and implemented a parser & VM, which is mostly a subset of Javascript. The other option I'm considering is embedding Python. From either of them, it should be possible to call external VS macros, which use VBA.

I'll be happy to hear other people's thoughts on this.

I like the idea of a custom-built language but before you introduce the one you have already built, consider another example of such a language which took a somewhat unique approach: DEC's TPU language.

TPU was a custom language designed specifically for text processing.  As such, it had commands in it which were specifically oriented towards the types of things which are done in text editing such as buffer handling, search and replace, case-shifts, etc.  It was, in fact, so suited to this task that they wrote their Eve editor, a very powerful editor in its own right, in TPU.  Eve's scripting language was, of course, TPU, and it was possible to write some very sophisticated extensions to the editor rather easily by using it.

The point to take away from this is that whereas most tools, when they have scripting capablity, simply take the features available in the tool and make them available to a general purpose language through some generic syntax such as function calls and while this adds a lot of power, I think you can sometimes get more bang for your buck by having a language designed around the objectives of the tool so that, rather than just allowing automation of functions which one can do manually in the tool you can, perhaps, easily extend the tool to do things it was never designed to do in the first place.  While this may still be possible using a general purpose scripting language, it might not be as easy.  Of course, vi is already quite powerful and one can do some very powerful things using just the map command or ex macros but it is just something to consider.

One other thing I would recommend is to be wary against falling into the two traps that far too many tool authors do when adding scripting: 1. Providing commands for action without providing commands for determining status; 2. Exposing such a limited subset of the tool's capabilities via scripting that there is little incentive to even learn the scripting language since most things can't be automated anyway.  Re: point number 1, it is, for example, difficult to write a macro to open a special file when needed if there is no way to tell whether or not that file is already open.  Likewise, it is difficult to write a macro to do something to the first character in every line if you have no way of determining which is the first character in the line.  Unfortunately, these types of problems are all to frequent when scripting is added.  On the other hand, as one whose tool is integrated into the environment of other tools, I suspect that you know all too well about the frustrations of tools which have too many limitations on what they expose for automation.

- Les

8

Re: ViEmu 3.0 timeline

Les,

Thanks a lot for thoroughly addressing this point. Indeed, it is a serious point and it could make a big difference towards the future of ViEmu.

I was not familiar with the TPU language, but I am clearly aware of the advantages of a language designed for the actual task at hand, rather than a general purpose lightly fitted for the goal. The area of programming language expressivity has fascinated me for a long time, and I'm actually doing quite some research in this area.

Would you have some pointer to an online resource where TPU is properly described? A few minutes of google-digging turned up nothing of much reference value. It would interesting to have a look.

For ViEmu 3 scripting, though, I'm not really looking at innovating a lot: the case is that I have many requests for features that are only interesting for a tiny minority among an already small segment (ViEmu users), and it simply makes no business sense for me to implement them, but there's no reason why it shouldn't be a 5 minute job for whoever is interested, given a good scripting ability. Providing an area where users can share snippets of ViEmu-customizing could also help make the ViEmus more useful and attractive at a reasonable cost on my side.

I'm aware of really poor scripting solutions out there, in some popular text editors even, and I hope to avoid the trap. Providing good query mechanisms will be very interesting for full ViEmu customizability, hopefully I can address this well.

The decision between using my current own language (a javascript-alike interpreted language) and embedding python is leaning towards using my own language. The reason is that, even if Python is very popular, using my own language allows my code base to be more homogeneous, and that makes the whole ViEmu codebase more flexible towards future improvements and migrations.

Built-in VS-scripting was discarded early on, as the ViEmu core engine itself is quite host-agnostic, and I want the solution to work in the different hosts where ViEmu currently works (Word & Outlook, SQL Server Mgmt Studio, and my kodumi text editor prototype).

Thanks for sharing your thoughts again,

  - Jon

9

Re: ViEmu 3.0 timeline

admin wrote:

I was not familiar with the TPU language, but I am clearly aware of the advantages of a language designed for the actual task at hand, rather than a general purpose lightly fitted for the goal. The area of programming language expressivity has fascinated me for a long time, and I'm actually doing quite some research in this area.

Would you have some pointer to an online resource where TPU is properly described? A few minutes of google-digging turned up nothing of much reference value. It would interesting to have a look.

I don't know the recent history of DEC but the results of my web-search would seem to imply that HP/Compaq has acquired some sort of interest in them as they apparently are distributing an OPENVMS product based on DEC's VAX/VMS OS, as well as other DEC software.  I found the following documentation available there and there were quite a few more hits which I didn't bother to explore:

Extensible Versatile Editor Reference Manual
http://h71000.www7.hp.com/doc/73final/documentation/pdf/OVMS_73_EVE.PDF?jumpid=reg_R1002_USEN

Guide to the DEC Text Processing Utility
http://h71000.www7.hp.com/doc/73final/documentation/pdf/OVMS_73_GD_DEC_TPU.PDF?jumpid=reg_R1002_USEN

DEC Text Processing Utility Reference Manual
http://h71000.www7.hp.com/doc/73final/documentation/pdf/OVMS_73_DEC_TPU_REF.PDF?jumpid=reg_R1002_USEN

I certainly can understand why you wouldn't want to invest a great deal on "innovation" for this product, but I knew that you have your other editor project in the works as well, so clearly you have an interest in this sort of thing.

- Les

10

Re: ViEmu 3.0 timeline

Les, thanks for the detailed info. Very interesting, I had never heard of TPU before, and that info is really extensive.

I am indeed planning to some innovations in text processing, both in the editor and in the current tools, I just meant that the goal in ViEmu 3.0 is just to have scripting abilities for better customization.

My vision in the future involves ViEmu and Codekana sharing the core with kodumi (the text editor), such that all of them can enjoy shared and continuous improvement.

Have a great weekend,

  - Jon

11

Re: ViEmu 3.0 timeline

admin wrote:

Les, thanks for the detailed info. Very interesting, I had never heard of TPU before, and that info is really extensive.

TPU is pretty cool and the EVE editor, as conventional text editors go, is one of the better ones I have used.  I tend to write a lot of macros and scripts to customize my environments and when I was working on DEC systems I was alternating working with Unix systems so it gave me a chance to contrast my environments.  I noted that on UNIX, I would frequently "shell out" to the OS in my vi macros to use the vast power of the Unix command set to enhance the power of vi.  On the other hand, working in EVE on DEC, in addition to my usual editor macros, I would frequently write extensions to the editor which manipulated the file system, etc., much of which was only tangentially related to the editing process.  It finally occurred to me that what I was really doing was using the vast power of TPU to enhance the power of the VAX/VMS command set which, compared to UNIX, was very weak.  One of those weird synergies.

- Les

12

Re: ViEmu 3.0 timeline

I've never been one to customize my editor heavily. This might change if you didn't have to reconfigure it on every machine, every time you reinstall, etc... but meanwhile, one of the reasons I love vi/vim so much is the awesome power without having to configure anything. 100s of commands out-of-the-box!!

  - Jon

13

Re: ViEmu 3.0 timeline

In case anyone is watching, I just wanted to let you know that I'm finally set on using my own custom language for ViEmu scripting. It's a subset of javascript, so that should help break the ice. On the other hand, having my own parser, compiler and vm implementation in my stylized C++ will allow me much more flexibility when I want to move forward: implementing it on other platforms, partially automating a possible port to Java or another language, etc...

Having a single codebase in a common language, using common constructs, can be very helpful. Processing the Python codebase isn't something I'd like to do.

14

Re: ViEmu 3.0 timeline

Is there an updated timeline on when we might see the next ViEmu version? I can get by, but the one feature that is niggling in its omission is multi-key remap. I use it heavily in vim, especially <leader> mappings. When switching to ViEmu I still inadvertently use those mappings - and hilarity ensues similarly to when you think you're in insert mode and type away, and suddenly all your text is gone... smile

15

Re: ViEmu 3.0 timeline

I think using python as scripting language would be wise option. That way the exiting knowledge can be used to create the scripts faster. Also with Iron Python integration possibilities the .NET code also can be used.

16

Re: ViEmu 3.0 timeline

Tomlu,

I don't have an updated timeline yet, although a few features are implemented, the biggest one isn't yet (scripting), and there are a few "new kids on the block" that need attention, like MS having a completely new editor architecture for the next version of Visual Studio. I will try to push the multi-key mapping feature somewhat, as there are a few people asking for it.

Regards,

  -- Jon

17

Re: ViEmu 3.0 timeline

Madhan,

Thanks for your suggestion about Python. I'm still undecided about it, although I've been using Python for other projects lately (I had never tried it), and I'm very happy with it.

Regards,

  -- Jon

18

Re: ViEmu 3.0 timeline

Jon,
I'm in favor of continuing to push small improvements to ViEmu ahead of the scripting. I see why it makes sense for you to ship a custom scripting implementation that can be shared by all your products, but for my usage the built-in vs macros are ok. On the other hand, I'm really missing multi-key mapping, and the ability to source external files.

19

Re: ViEmu 3.0 timeline

gmoothart,

I couldn't agree more with you. I think I made the mistake of envisioning a "great" ViEmu 3.0, and I think that has gotten in the way of a continuous stream of small but important improvements. I think I will be switching the focus more in this direction (as soon as I can catch up with several outstanding support issues), and as a result I will be able to provide more frequent updates, including things like scrolloff, multi-key mappings, etc... scripting will have to wait a bit, as it is a huge effort, and resources are scarce, as I'm the sole developer.

Thanks for the suggesttion and best regards,

  -- Jon

20

Re: ViEmu 3.0 timeline

As an avid user of ViEmu for VS 2005/2008 for about 3 years now, I'm getting ready to start a new project using Java and Eclipse. Going back to an earlier post in this thread (http://www.viemu.com/forums/viewtopic.php?pid=1814#p1814) I was wondering if there has been any progress made with regards to porting your code to Java. I would love to see ViEmu inside Eclipse, as the vi(m) plugin (called viplugin) available today can be a little flakey, and is not compatible with some of the editors inside of Eclipse.

21

Re: ViEmu 3.0 timeline

Shawn, apologies for the delay in answering. I have no plans to port ViEmu to Java environments, including Eclipse. Implementing a vi/vim emulator is a huge effort, and it is rarely worth it. Now that I have a fully regargetable, template based C++ vi/vim emulation core, which is the base of all the ViEmus, such environments are a an option, but implementing a full engine in Java, and learning all the issues of Eclipse would be a huge effort. I talk to people using Eclipse and viPlugin every day, and I'm aware of the limitations, but unfortunately I can't work in it. Hopefully someone will!

On the other hand, ViEmu for VS2010, using C++/CLI (the .NET incarnation of C++) is now starting to work and will be ready for testing really soon, and for full production use in some time.