[accidental double post deleted]

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

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

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

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

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

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.

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.

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

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