The growing pains of NGEDIT

I don’t know whether this will get gigabytes of spam down my pop3 stream, but I’ve published my e-mail address on the sidebar. Feel free to get in touch.

Right now, I am writing the scripting language compiler for NGEDIT. It is loosely based in JavaScript (typeless variables, object oriented), and so it has a C-like syntax. It generates code for a simple stack machine. I’m using a handwritten recursive-descent parser to parse the code and generate the bytecodes as parsing is done.

I’ve noticed two interesting things in the process.

The first one is how much of C/C++ syntax is unnecessary. Python did away with a lot of it, but I never thought that even in C/C++ most stuff could be parsed without any problems with many commas and semicolons left out. Ever wondered about class/struct/enum declarations ending in a semicolon, while functions don’t have one? In the parser, it’s as simple as saying skip next token if semicolon after the decl/def. After most statements, there is no ambiguity if the semicolon is removed (expression parsing stops if the next token isn’t a possible continuation of the expression). It is possible to leave out the commas between function arguments and between identifiers in an enum definition, even if they carry an explicit = expr initialization.

The second one came onto me when I was writing the intermediate structures that hold the code generated for a full function and the code to evaluate an expression. I had to separate the code for the expression, as it can’t simply be added to the tail of the function (as can be done with the statements). It turned out that the structure to hold a compiled function and the structure to hold a compiled expression are identical! (at least, given that I was storing the function signature separately). In NGS (the NGEDIT scripting language) all function return values, so that is common as well. This reminded me of one extension GCC used to have years ago… a body of code surrounded by braces can be embedded in an expression, resulting in the value of the last statement. I don’t remember being able to use return inside the code, but it would make sense. In this way, we could write:

int a = { if (b) return 1; else { while(c--) do_something(d, e); return get_something(); } };

And if we used the parser with optional separators we could even write:

int a = { if (b) return 1 else { while(c--) do_something(d e) return get_something() } }

The optional separators are already working in the NGEDIT parser, but I don’t plan to implement the code-as-subexpression trick.

I just fixed the padding/border problems with the page, so it shows up fine with IE. The fix involves using Mozilla specific hacks to make it understand width/border/… in the same way as IE, that is, deviating from the W3C standard. It’s ugly, but it seems to be one of the standard solutions. The good thing with standards is that there are as many as you want, and if you don’t like them, you can always create a new one.

Now I just need to apply the design to the blog so that it doesn’t show the standard WordPress look, which cries amateur. Some more CSS hacking down the road.

After some design work with the Wacom tablet, some digging into CSS Zen Garden in order to learn some CSS, and some CSS trial & error, www.ngedit.com now shows a nice front page.

Unfortunately, it only displays well with Firefox and it looks really ugly on IE. I hope I’ll be able to fix it soon enough, before no one sees it like that.

My first experiences with browser compatibility. Nasty.

You have to see this keyboard. Lets you switch between Qwerty and Dvorak at will, apart from impressing anyone around. Now I want a laptop with the same concept.

What’s NGEDIT? NGEDIT is my project for a new text editor, which I’ve been developing for the past months, and which will hopefully be ready very soon.

You may be asking yourself, why another text editor? There are dozens of them in the market, of all types and sizes, prices and weights, colors and fits. Why would anyone in his right mind think on developing yet another one?

The answer is actually simple. It turns out that I have have a set of features in mind that will make current-day text editing look prehistoric. Of course, only time (and a lot of work on my part) will be able to prove or disprove this.

Before I can start writing all the innovative features, I need to implement a full-blown modern text editor: multiple text file formats and character sets (codepages, DBCS, Unicode anyone?), multi-file and multi-window support, fixed- and variable-width fonts, syntax highlighting, keystroke and programmable macros, multi-file find&replace, regular expressions, tons of preferences,… you name it.

I’m currently in the process of developing this first text editor, the first step towards the full NGEDIT. I plan to have a first release with:

• all the solid features of a modern text editor
• some advanced ones that are not very common
• some very carefully crafted usability-oriented features
• and some very specific and useful features that aren’t found in other editors

All in all, I think NGEDIT 1.0 will already be a winner over other editors out there, if not in all cases, at least in many of them. I hope to have a downloadable trial version soon enough that you will be able to see it yourself.

I will be posting about how development progresses, the process of setting up the web store infrastructure, there will probably be some rants, and miscellaneous other stuff. Feel free to comment on any issue.