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.

closed as off-topic by ChrisF Oct 21 '13 at 8:07

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – ChrisF
If this question can be reworded to fit the rules in the help center, please edit the question.

  • a commonly used term for this functionality is context-aware – doug Apr 27 '12 at 8:49
  • thanks, are you suggesting fixing at least the title? – Maksee Apr 27 '12 at 9:06
  • What's the real question you're asking? Are you looking for examples of editors that have such domain-specific features? – Bryan Oakley Apr 27 '12 at 11:01
  • @Bryan, yes, examples and it's better be something intended to advance conventional editing as a whole – Maksee Apr 27 '12 at 11:21
  • 1
    @Maksee not really, because i don't know if there are synonyms, etc. If you use a Mac, TextMate should have what you want--the specific functionality is embodied in scope-selectors (manual.macromates.com/en/scope_selectors#scope_selectors) – doug Apr 27 '12 at 11:21

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.

  • Great, the only feature missed from my list is layered navigation although just tried the editor, maybe there is. The editor fills good at hands so this kind of control can be helping and comforting for users. – Maksee May 11 '12 at 4:36
  • You're right this form of navigation isn't yet supported in the editor referenced in my answeer but it is a good idea so I will try to add this. – pgfearo May 11 '12 at 7:08

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.

  • I see your point, but I believe the "keyboard" world it too conservative. You can define macro for any feature in an advanced editor but you will most likely use only the ones widely known before. My idea appeared 10 years ago and saved me dozens of days, but I doubt it had more than dozens of followers – Maksee Apr 27 '12 at 8:59
  • @Maksee did you post the question with agenda to somehow promote "your idea"? – gnat Apr 27 '12 at 9:23
  • 1
    @gnat, No, it was a side effect. If the site allowed editing comments later, I'd delete the sentence based on your concern. – Maksee Apr 27 '12 at 9:32
  • 1
    @Maksee: Your 'idea' is even older. Look into 'tag files', especially the ctags program and its (more powerful) drop-in replacement 'exuberant ctags'. Both vim and emacs can consume tag files, giving you pretty much what you describe, and then some. And yes, it's a huge productivity boost. – tdammers Apr 27 '12 at 10:07
  • 1
    While it's true that learning a general purpose editor means you don't need to learn more than one tool, for most people a general purpose editor is just too complex. For example, consider someone who is a manual QA tester moving into automation. They may have no programming experience, or only a smattering. Do you really want to make them to learn and configure vim or emacs, or does it make sense to give them a domain-specific editor with a short learning curve? You can make toast with an oven, but sometimes a toaster works better. – Bryan Oakley Apr 27 '12 at 11:13

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.


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.

  • what are the main features that differ it from table editing in general rich editors? – Maksee Apr 27 '12 at 12:04
  • 1
    @Maksee: that's hard to answer because I don't know what features of "table editing in general rich editors" you are thinkng of. The tool is for editing test cases for the robot framework testing framework, so it has tools unique to that data format. For example, you can convert selected statements from a test and convert them to a keyword definition, it has support for robot's somewhat unique continuation characters ("..." in first cell of a row), syntax highlighting, ability to run the test from the editor, etc. – Bryan Oakley Apr 27 '12 at 23:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.