| I wouldn't even think about releasing a programming language without an accurate syntax coloring definition for at least one major editor, maintained side by side. Looking at code without coloring is like looking at a road atlas that has been photocopied in black and white. Even some grayscale cues are better than nothing. I actually run the Vim editor dynamically out of Apache to colorize TXR files. You can see that here and here: http://www.kylheku.com/cgit/txr/tree/share/txr/stdlib/struct... http://www.kylheku.com/cgit/txr/tree/tests/010/align-columns... The second example shows a mixture of two languages: a Lisp dialect and an extraction language. Both have their own sets of standard symbols (which intersect: there are some symbols in common). They are correctly rendered in a different color: the Lisp words are green, and the extraction language words are burgundy red. This kind of thing is very helpful. The Vim definition I maintain is quite accurate --- and not only for correct programs. I stuffed in rules so that errors are boldly flagged. For instance, even little things like using an undefined escape sequence in a character string or regex literal. (And it knows the exact set for all literals.) This works remarkably well; hardly any typos I make get by it. Syntax highlighting definitions also help with formatting;
they provide the editor with nesting cues for indentation. Working without this stuff this day and age is completely silly. |