New customs

I’m already using the scripting language extensively. I first had to complete array access code, and I also had to include “true”, “false” and “nil” (not “null”). I’m now fighting against the intrincacies of vi/vim emulation instead of against the language, so I’d guess it’s faring well.

I’m using the newly discovered style of avoiding all necessary syntactic sugar such as semicolons, commas, etc. The funny thing is that it feels comfortable everywhere except in a single place: I can not get used to leaving out the comma between function arguments. Given that arguments are typeless (the same as all other variables), it seems that something such as:

function IProcessKey ( key modifkey ) 

looks too much as if “key” was the type and “modifkey” the name, and my brain is already too hardwired to that.

On other issues, I’ve started working in a design for the blog – I already have a nice design, just need to work on some graphics elements and then work out how to integrate everything with WordPress.

And I’m also thinking about changing the name of the blog. I don’t like seeing “pains” up there prominently, it paints a negative picture of something which is a positive, enjoyable venture (if not completely painless).

13 Responses to “New customs”

  1. Jonathan Ellis Says:

    If you’re exposing your scripting language to the user (and I assume you are, since scriptability is one of the few places you might stand out), why not use a standard language like Python, LUA, or even Javascript? Nobody (by which I mean, maybe you’ll need both hands to count the number, at most) will be interested in learning Yet Another Language to script an editor nobody’s heard of.

    I mean, sure, it’s a labor of love and all but what I read here leads me to believe you’re going to try to get paid for it…

  2. J Says:

    Jonathatn,

    Thanks for your comment, you are actually the first person to comment in my blog 🙂

    I agree with you in that the world is not interested in yet another variant of a scripting language. Myself I don’t see any point in such a goal, and I can asure you that I wasn’t after bringing the world another such language

    That’s one reason the language is almost the twin brother of JavaScript, based in my knowledge of the language which is not the deepest.

    Using some other implementation of JavaScript, or Python or LUA, would require me to get to grips with their implementation API’s, which would possibly take almost as long as writing my own compiler/VM, and would certainly be much less interesting. Licensing problems may also arise, and having all code under my direct control is a plus for me.

    It isn’t actually JavaScript because it was simpler for me to just design the new language instead of looking up all the JS details. I’m not even sure whether JavaScript is usually compiled into bytecodes for interpretation, I just think it was the best solution for my application.

    It probably also helps that I do not find it very difficult to learn the two or three specifics of a C-descendant – it’s code that is really easy to read for anyone with previous experience in C/C++/Java/JS, which includes most programmers.

    I think it could be a good idea to turn it into proper JavaScript (or an adequate subset of it).

    As a final note, scriptability is not the place where I want NGEDIT to shine. Usability is, and I think that will come across as the product evolves. Scriptability helps in implementing part of that usability, and lets the user automate some common tasks when the need comes.

    Thanks and good luck with spyce!

  3. Jonathan Ellis Says:

    Good luck likewise.

  4. Doug Tolton Says:

    I see that you are putting VI support into the editor, not to start a flame war, but any chance of putting Emacs key chords in? By putting only VI emulation in, you are leaving out those of use who eschew VI in favor of the one true editor. 🙂

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

  5. Chris Hutchinson Says:

    I second the comment on Yet Another Scripting Language. Is it too late to consider switching to something standard? You discuss various similarities with Javascript, why not implement a stripped-back dialect of JS, so the syntax is compatible. Leaving out list separators in function calls looks v. alien to me.

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

  6. Marcin Kaszynski Says:

    Hi,

    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 🙂

  7. J Says:

    Doug,

    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).

  8. J Says:

    Chris,

    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.

  9. J Says:

    Marcin,

    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.

  10. Eric Sink Says:

    I actually like the scripting language idea.

  11. Rob Walling Says:

    It probably is easier/faster for you to write a new scripting language from scratch, but from a developer’s perspective a text editor would be more attractive if it used a language that we already know. Speaking for myself, I’m not going to take the time to learn a scripting langauge that only applies to one small subset of the programming world.

    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…

  12. J Says:

    Rob, I understand perfectly that the user couldn’t care less about the effort it takes me to develop the underlying scripting engine. It was a reason for me because it fits the bill I am trying to cover. The main goal is to write the vi/vim emulation layer and the inter-operation with MSDev. Users may be writing short snippets of code, but, c’mon, something like this seems so simple to look at, understand and modify:

    //—————————————————————————-
    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 🙂

  13. J Says:

    Sorry about the indentation, doesn’t work in comments 🙁

Leave a Reply