I'm not sure exactly what you mean here. If you're talking about my usage of mnemonics such as ol, understand that those mnemonics wouldn't find their way into

I'm not sure exactly what you mean here. If you're talking about my usage of mnemonics such as ol, understand that those mnemonics wouldn't find their way into neither the implementation nor the operation of the editor, I just used them in my explanations because I thought the operation streams would take too much space otherwise. But in general I'm a big fan of using long-and-meaningful-identifiers. If you're saying that it's not worth it to make a structure editor just to have more CPU efficiency, I wholeheartedly agree. It's true that a structure editor would probably be more efficient on that level, but it's only a very minor bonus compared to the real advantages of the computer always being fully aware of the editing context you're in (thus helping in ways it normally couldn't), and without the need to write such a complex piece of software as a reliable incremental parser. If you're saying that the keystroke savings are not worth it, I'll have to admit the very simple example I used doesn't make it seem very worthwhile, but the benefits of a structure editor would become much more obvious the more you looked at complex examples of the kind of thing it could do. I didn't even talk about the modification of structure yet. I can't tell you how many times I had to edit (something (stuff) (something2 (stuff2) body1 body2)) into: (something2 (stuff2) (something (stuff) body1 body2)) and how slow and painful it is. With a structure editor I could do it with perhaps 3 key presses... And there are lots of use cases like this one. If you say that I could simply write an emacs-lisp function to do it and bind it to a key, you'd be right and you'd be missing the point.