Domain-aware code text editors [closed]

Question

General text editors don't change greatly. Syntax highlighting and code collapsing are not big changes really. If an editor is structure or domain aware, this usually comes with a different layouts - treeviews, context-menus, drag-and-drops and so on. So are there good example to add more domain control when editing with caret, text selection and so on?

When I think about explaining this with example, what comes to mind:

• Sync control (it's when you delete first i in <div>...</div> this automatically changes to <dv></dv>
• Read-only control (it's you're at "/" at the fragment above you can't edit, but if you select <div> and press Del, both are deleted
• Layered navigation. Probably different modes when the caret bypasses irrelevant layers when you press Left, Right and so on. For example if you're in text navigation for html, then all tags are bypassed
• Copy-paste control. Selected fragment should contain a valid sentence for domain and the place to insert to should also be compatible with it.

These are just examples for you to recall the real world editors where you met something similar.

Probably there are editors that allows one or several things from this list, but I suppose that partial solutions is no help and even can do harm and cause inconvenience. So the question is more about complex solution intended for overall improving of productivity in the general text editors.

Answer 1

I developed a text editor that was 'domain aware' but it's probably best described as 'domain-specific' in that it was written specifically for XSLT.

It was built particularly with whitespace issues in mind. In XSLT, whitespace in the source code needs special attention because it will most likely end up in the result tree.

Most editors rely on the insertion of extra XML elements to separate code-formatting whitespace from whitespace intended for the output - this adds to the verbosity of the code and reduces readability. This new editor uses Virtual Formatting which avoids this issue by simply using dynamic margins to indent XSLT automatically.

The issue with this is users can't fully benefit from Virtual Formatting unless other editors also provide this option. Otherwise, as soon as a virtually-formatted XSLT file is opened by an ordinary XSLT editor a whole load of unwanted whitespace characters are added - to retain formatting.

I've failed to persuade other vendors to even consider this approach to formatting. What I've learnt from this is that text editors can't really change because any change would be disruptive. Most developer's want to use generic text editors that can work adequately with any grammar/syntax rather than use ones dedicated to a specific task.

Answer 2

The usual UNIX text editors (emacs, vi and its various clones) are highly extensible and can probably be configured to do most or all of the features you listed.

vim, for example, provides a range of features out-of-the box that would either allow what you describe, or achieve the same goal on a different path. For example, the it and at ('inner tag' / 'a tag') motions can be used to apply all sorts of general editing operations to an XML tag or its contents. Writing a macro that auto-closes a tag is trivial. Skipping can be achieved using tag-based motions in combination with general movement commands. vim also has configurable syntax-aware folding, and I guess getting it to fold XML properly shouldn't be too hard. If that's not enough, you can pipe any part of the current document through an external command using the ! family of commands. And finally, vim has some integration with build tools, and can be configured to parse their output to position the cursor at any error.

I am all but an emacs expert, but I'm fairly positive that emacs can do the same things, or their equivalents in the emacs paradigm.

Read-only control is a feature I would hate - it's my text, it's there, there is no reason to deny me from editing it if I so choose. Signalling that the document is wrong through aggressive syntax highlighting, and providing comfortable macros to manipulate text in a domain-specific way, is a much better choice.

But the most important reason for using a general-purpose text editor over a domain-specific tool is that you only need to learn one tool - this means that you can (and probably will) learn this one tool inside-out, and this in turn means that a tool with a crazy-steep learning curve is perfectly OK, as long as it pays off in terms of productivity. Such an expert's text editor doesn't need a graphical UI, it doesn't need to spend system resources and screen real estate for discoverability, and it can assume that I know what I'm doing instead of trying to guess where I'm going and suggesting solutions.

Answer 3

One editor which is in my humble opinion a beautiful example of context-sensitive editing is GNU TeXmacs. Try it out, it's open-source and shows exactly the pro's and contra's of context-aware editing.

Answer 4

I'm working on an editor with such features. It's a plain text editor designed to edit data that resembles tables, where columns are delimited by pipes (actually, space-pipe-space). Pressing tab will move you to another "cell" like a spreadsheet, and there are commands that deal with "cells" and "rows" rather than "words" and "lines of text". It has features to align columns, and to detect contiguous rows with an equal number of columns (each row potentially can have a different number of columns). It also knows about the somewhat peculiar variable syntax, table headings and so on.

The jury is still out on how successful this type of editor is, but I think it has some potential. While power users can still configure their industrial strength editor (ie: vim, emacs) to do the same things, there's a very large segment of the population that don't such tools. So while, yes, you can do this with emacs, most users (that I'm targeting, anyway) want something less complex.