programming/FancyProgrammingEditors written at 01:46:27; Add Comment
My take on fancy editors for programming
Recently on Twitter there was a little conversation (1, 2, 3, 4) about smart editors for programming, by which people meant editors that support things like auto-indentation and syntax highlighting. I have to confess that I have a very ambivalent attitude towards such fancy (or smart) editors and that I often wind up not using them.
In theory an editor with auto-indentation, syntax highlighting, and so on is a great thing. In practice, the implementations of all of these are often not what I consider well done; syntax highlighting often looks bad or unreadable and auto-indentation can behave in ways that irritate me (for instance, using the tab key in a comment had better insert a real tab). When things are well done it's great and I love it, but there's a very fine line between something this nice and something that is sufficiently non-nice that I don't want to touch it and will switch to a stupid editor just to get away from it. Stupid editors are not as nice as a fancy smart editor, but they have the great advantage that they don't get in my way and don't make me want to claw my eyes out.
To be concrete my default editor for programming and development work is GNU Emacs, in which I am a lapsed expert (I once was very into it but have let that slip over the past long while). However the only syntax highlighting it does that I've been able to stand is what it does for Python; for everything else, including C, it has a set of colours and a division of what it highlights (and how) that range from simply ugly to completely unpleasantly bizarre. Its autoindentation smarts work just about right for Python and decently right for C (after I spent some time years ago customizing it), but tend to get in my way for HTML and shell scripts. Thus I have a split in my editing usage; I edit Python in full fancy GNU Emacs, C in GNU Emacs with syntax highlighting turned off, and generally everything else (HTML, shell scripts, Makefiles, etc) in a stupid editor (often vi).
Some of this I could change with customization; for example, I could modify syntax highlighting colours for C in an attempt to find a good colour set that doesn't look like a fruit salad explosion. But this sort of customization can only take me so far because it's limited to what the GNU Emacs mode in question was designed to let me easily alter. Completely changing how the C mode or the shell script mode highlights things is not something I can do short of surgery to the ELisp code. Similar things apply to the fundamental auto-indentation models used for the various languages; I'm probably not going to be able to persuade the shell script mode that hitting tab inside a comment should insert a real tab without some significant ELisp.
This isn't just a limitation of GNU Emacs, it's a limitation of how all fancy editors work (if anything GNU Emacs is better at this than other editors). All of them are going to have limits on what you can easily customize about their behavior and all of them may not work right for you as a result, for some or all of the languages they support. Sometimes the right answer is a plain editor.
(I suppose I could work out how to turn off all of GNU Emacs's smarts instead so I can use it as a plain text editor, but honestly there doesn't seem to be much point to that. I have a windowing system and multiple windows, so it's not like I have to do everything inside a single application.)
* * *
Atom feeds are available; see the bottom of most pages.