My structure editing theories

I was writing a post on the keyboard layout topic and my editing got a bit out of hand so I thought I'd post a new topic... Enjoy.

I have a theory that using a keyboard layout and structure editor perfectly tailored to the specific editing task, you could achieve really insane productivity. Imagine editing mathematical formulae or s-expressions (or mathematical formulae represented as s-expressions ;P) at 60 significant operations per second...

I think the current idiom of editing text with what I consider primitive edit assist (autoindent, parameter hinting, completion) is really inefficient.

First, there's the mental overhead of converting each significant operation into a stream of mostly raw-text editing operations... It's a bit like compiling a high-level language in your head, then writing assembler instructions. Not only does it unduly take mental processing power and keyboard operations on your part, but a lot of the semantics of what you meant gets lost in the process.

Which brings me to the next point: by editing text that then gets parsed in complex manner for edit assist purposes (syntax highlighting et al.), it makes the parser much, much more complicated because you have to make an incremental parser that will account for all the semi-incorrect states that you go through, and it must degrade features in a "smart" manner when it can't completely understand the editing context you're in. With a structure editor that will only let you go from one consistent state to the next, the editor would always know exactly what the editing context is and could easily provide great edit assist efficiently.

Let's have a look at an example. Let's say I want to write this:

  (:html
   (:head (:title "An example"))
   (:body
    (:p :class "benefit" "Putting things in quotes (\") is easier!")))

With an s-expression structure editor, the operations would be something like (ol = open-list, ie = insert-element, os = open-string, ul = up-one-level, the rest are raw keystrokes): ol, ie, :html, ie, ol, ie, :head, ie, ol, :title, ie, os, An example, ul, ul, ul, ie, ol, ie, :body, ie, ol, ie, :p, ie, :class, ie, os, benefit, ul, ie, os, Putting things in quotes (") is easier!

So that would be 24 significant operations (= 24 keystrokes) to handle the structure only, and we could reduce more by saying for example that ol implies ie if we didn't just create a new element.

Notice that I didn't need to escape the double quote in the string since the editor was completely aware that I was in a string-editing context. We could have many such embedded helpers. Let's say I'm writing Lisp code: (format nil "It's ~A today!" today). The editor could easily detect when I'm editing a format string and help me with ~ parameter hinting and such. You know how complicated those expressions can get sometimes...

And of course, my example was actually a representation of HTML so we could have a more specialized structure editor for that (based on the s-expression one), so the operations would be something like (on = open-node, ic = insert-child, ia = insert-attribute):

on, html, ic, on, head, ic, on, title, ic, os, An example, ul, ul, ic, on, body, ic, on, p, ic, os, Putting things in quotes (") is easier!, ia, class, next, benefit

The operation names are different from the s-expression example, but similar operations between the two editing modes would of course map onto the same key.

Here we have 17 significant operations (= 17 keystrokes) to handle the structure only, and again I'm sure we could reduce further. Notice how I have less to type here, for example when I open an HTML node the editor knows I'll necessarily insert a keyword as the first element.

Also notice how I (hypothetically) thought about inserting the class = benefit attribute after writing the child, but I simply needed to invoke the insert-attribute operation (= 1 keystroke; By the way by keystroke I mean just one key and not CTRL + something) and the editor knew I'd necessarily insert a keyword and then a string. If I had invoked ul at the end the editor would have returned me to the place I was when I invoked ia.

Also notice that the editor could easily switch views, if someone who hates s-expressions comes to see my code I could just flip a switch and a traditional HTML representation would be shown. And I could edit it exactly like the s-expression representation at full speed. There could be many such views.

I also have ideas about relying less on file structure and more on "query-views" but that's for another day.