//—————————————————————————-
function IProcessChar ( key, modifkey )
{
if (s_fnHandler) { // For example, after pressing ‘r’ or weird stuff within INPUT mode
s_fnHandler(key, modifkey);

// Were we waiting for a pending motion?
if (s_PendingMotion) {
if (s_PendingMotion(false))
s_iWaitingWhat = W_COMMAND;
}
…

As a result of this thread, now I think that it might make sense either to derivate NGS towards actual Javascript or implement Lua or Python support in the future (but not before the first release).

This is the only scripting I ever had to do for vim, in order to switch between a ‘.h’ file and its corresponding ‘.cpp’ file with a keystroke:

function! OpenMatchingCPP_H()
if expand(”%:t:e”) == “h”
e %:t:r.cpp
else
e %:t:r.h
endif
endfunction

String manipulation is more awkward to me, although it probably didn’t take over 30 minutes to figure out and hack in.

Looking at other editors out there: UltraEdit has a language so simple that I couldn’t figure out how to write the above h-cpp macro, and think it is not doable. MS Visual Studio seems to use VBasic or something similar. Emacs… as they say, it is actually a good OS, it just lacks a decent editor. I don’t even remember what other editors use.

There are (or have been) other editors with good scripting support, such as The Semware Editor, and there still are around there (”Soft as it gets”‘ ED, Lugaru’s epsilon, …). I wanted a language powerful enough not to stumble into stupid limitation walls and to develop a few of the features of NGEDIT which seem better served in a scripting language than in native C/C++.

I was almost about to complain about the lack of a decent debugger for NGS until I write one, I’m just afraid you’ll all jump at my neck to bite me for making The One Wrong Decision

In terms of usability, JavaScript or Python would be a big selling point over a proprietary scripting language.

Keep up the good work! It makes for interesting reading…

Thanks for the advice. I think your points are right, and I take note regarding promotion through scripting language user groups. Thanks for your support and I’ll keep your comments in mind.

The NGS language is almost a subset of JavaScript. Except for the fact that every object in NGS is both an object and an array at the same time, and the lack of objet protos (so far), I’d have to check the specs to see where it deviates.

Regarding syntax, my post may have not been clear enough. I’ve made the commas and semicolons optional, they keep the same meaning as always and you can ellide them where they are not necessary for the parser. You could do this to a C/C++ parser, and no legal programs would change their meaning, while many interesting illegal programs would become legal. It’s just allowing the user to get rid of innecessary punctuation.

The optional punctuation is more of an interesting experiment than anything else, which I decided to do as I wrote the parser and became conscious of the amount of “red-tape” in C-like syntax.

Turning it into real JavaScript should be quite painless, and I’ll consider it later down the road when the to-do list is less bulky.

Thanks for the support. I’m implementing vi emulation because it is what I need in order to become a full-time user of NGEDIT. I plan on implementing other modes later - emacs keychords is a good candidate although its full underlying lisp system is not (even if using lisp as the scripting language for NGEDIT did pass my mind).

about the scripting language issue again: it is not just a matter of implementation or api. I created a scripting language for a commercial product once and since then my advice to everyone is “don’t do as I did”. The hassle is much, much more than it initially seems. Next time I’ll just use Lua.

Creating a new language means, among others:

1. documenting it: writing a tutorial or two, writing language specification, some examples and so on,

2. supporting it: you will get bugs to fix, you will get “why doesn’t this work” questions, you will have to baby-sit new users, you will get feature requests,

3. writing all the base code (libraries) in the language yourself.

If you choose to use an existing language that already gathered a community around itself (like Lua or Python) you can simply tap into its resources — polished implementation, documentation, libraries and mailing lists you can divert some of the support questions to. Plus, you get a large group of people that might check out your editor simply because it uses a language they know and like. You might even find some evangelists for ngedit among them

You really shouldn’t undervalue the free publicity and marketing consequences of this.

That said, good luck with the editor. There is definitely not enough software developed with usability in mind

Good luck with it all. Glad you’re implement vim support.

Good luck with the editor, personally I think there is plenty of room in the windows market for a good developer text editor.