1. all text is "alive" for the purposes of executing/finding
2. select/execute/find for left/middle/right mouse clicks
3. ed-like command language (sam) plus structural regexes with conditions and loops
The lack of syntax highlighting is a usability problem, but also the fact that there's no good way to integrate it into something like acme is evidence that we're still missing one of these dimensions. The general problem seems to be recovering structure from the text on-the-fly and doing something with it, like highlighting or special structured editing. Emacs gets its "power" by letting the programmer directly manage what's on the screen and what happens for any key press. Editors like SublimeText and TextMate just have keybindings and language grammars, and syntax highlighting is sort of built-in.
If we had a good general solution to this problem and could plug it into acme, acme would really be compelling. But I can't really use an editor that lacks syntax highlighting.
And of sam and how some of the best programmers I know use sam[1] a language that provides even less configurability than acme.
[1]: http://sam.cat-v.org
http://ipn.caerwyn.com/search/label/acme
If I understand correctly, these hinge on 9p; instead of Acme worrying about keypresses, it's some 9p client worrying about characters read. A clever solution, and self-evidently powerful, but with the obvious drawback that most of us aren't running Plan 9 or Inferno. And we still have the problem of syntax highlighting.
Editors are vastly more complex than necessary.
I want an editor like google.com. It's simple "sentence" model totally wins. Of course, creation instead of consumption requires additional abstractions.
Three dimensions build an entire universe. An editor built with three choice abstractions could outstrip every other editor conceived. Ever.
Somebody do it.