An accessible programer's editor

[compilerbitch]

I'm actually very seriously considering writing a programmer's editor from scratch, incorporating voice recognition and ideas from the Dasher interface (http://www.inference.phy.cam.ac.uk/dasher/), along with a few ideas of my own. Leo Dearden (the friend with major RSI I mentioned) has also contributed some really good ideas. I need something like that so much myself, it just has to be done. This is an idea that has been bubbling away for some time now, but has now probably reached a point where it warrants being made a little more public.

Leo called the idea a 'low friction editor'. The idea is that everything in the editor should be as smooth and easy as possible. You should be able to type by actually typing the old-fashioned way, by voice recognition, gesture recognition if you have something Touchstream-like, or through a Dasher-based interface. All of this should be seamlessly integrated. The editor will use a grammar definition of the language annotated with layout rules, so if you open an existing file it will parse it into an internal, higher level form. This will allow really good syntax colouring, of course, whilst also being a convenient way to synthesize new chunks of code in a syntactically correct way.

I want to be able to point at a line of code, then say, "Insert while loop" and have the editor do it. I want to be able to select an STL object and have the editor automatically generate a loop that iterates over it. And that's just C++... I also want it to be able to edit Haskell, marked up English text in LaTeX format, etc.

Personally, I don't really see the Dasher interface as a keyboard replacement for anyone who doesn't happen to be disabled. But it could be a great way to select from tree-structured menus, especially where the menu options have relevance weightings. Like, for example, selecting code templates for inclusion.

Having said that, if the user happens to be disabled, Dasher-style input can be the difference between a career and no career.

The editor I have in mind will basically do all of the above, including genuinely usable voice recognition. I'm not necessarily trying to write an editor that will replace emacs or vi, although it might ultimately have that effect. No, what I'm really interested in is making it possible to edit code as quickly as possible, if necessary without using a keyboard *at all*. You should be able to drive it completely by voice, completely by pointing device (e.g. pen interfaces, eye trackers, mice, etc.), completely by keyboard, or any combination of the above, using a minimum of movements in all cases. This equates to minimum possible RSI exposure, and also (possibly, ideally, maybe) fastest possible editing, once you're used to it. I can forsee myself using a combination of approaches, all at once.

All the technologies exist, albeit independently of each other at the moment. Bringing them together will take work, of course, but for many people, myself included, an editor like this could really be a career-saver. I have a feeling that it might just become rather popular as a general purpose editor anyway. I think editors have been stuck in an emacs/vi dominated rut for far too long. Undoubtedly, thy both work well, and will never be completely replaced. But, try using vi with voice recognition... No. Something purpose designed is essential.

I'm posting here to solicit reactions to the idea. I will almost certainly write an editor like the one I am describing, because it is basically insurance for me. As an academic computer scientist, I must retain my ability to edit code and write papers using LaTeX. There are plenty of solutions if all you want to do is drive MS Word, but nothing whatsoever if you happen to be a programmer.

I am very keen to hear suggestions - ideally, please add them as replies to this LJ post. Please feel free to pass on the link to anyone who might bo interested -- the more feedback I have at an early stage, the better.

Comments

[sjmurdoch.livejournal.com]

One tool that might be worth a look at is GRASP.
In particular this has some interesting structure visualization (CSDs) and template inclusion facilities.

[catamorphism.livejournal.com]

You should look at the Harmonia project if you haven't already; I don't know how far they've come WRT voice recognition, but it's definitely something they're actively working on.

[trurl.livejournal.com]

It definitely sounds like a worthwhile idea. I see two ways that you can go with this. One is you can also try to reinvent editors in general, the other is try to layer this facility on top of something else, most likely emacs. The former has its advantages, because I'm always wishing that it were possible to start over an re-architect something like emacs from scratch. But it is also just a bit ambitious. The latter has the benefit that if you could make it work well with existing emacs packages and so forth, it would be easier to migrate. There are some software packages that I use that would be intolerable without their emacs mode. Plus, it emacs is itself more like an operating environment than a mere text editor, so it seems likely that you could just extend the user interface adding new hooks, and the elisp would be none the wiser.





Some of the structured editing ideas you have could probably be implemented directly in elisp, but I worry that the performance might be pretty poor with all the parsing and other computations that would need to be done. However, that could perhaps be alleviated by improving the technology behind the elisp interpreter.





While in principle I like the idea of having menus be optimized based upon usage, my experience with Win2K hiding menu options based upon usage patterns always kind of annoyed me. And there is the consistency issue. User interfaces should be "stable" in some sense, so that actions can become ingrained, and I worry that unless it is carefully designed, having the interface learn at the same time you are could be frustrating.

[mjg59.livejournal.com]

Damnit, I knew I was supposed to be mailing someone about Dasher, now I remember who...

The existing Dasher codebase is almost (but not entirely) completely unsuited to what you want to do in this case - the majority of the code is based on the assumption that each layer of the "tree" will be identical to the previous one other than for the probabilities. It's easy enough to hack around that if you're not interested in prediction (which is what I've done for some of the application control stuff), but it somewhat defeats the point otherwise.

On the other hand, alternative language models for situations where there's a somewhat more defined grammar than English are something that we'd be interested in taking a look at - Dasher works surprisingly well for writing C if that's what you train it on beforehand, but it's (unsurprisingly) far from ideal. I'm not sure how well it'd fit into your ideas, but I'd certainly be interested in seeing whether there's any useful cooperative work that can be done.