An accessible programer's editor
Jul. 27th, 2003 11:25 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
compilerbitchI'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.
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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2003-07-31 04:06 am (UTC)On the menu optimisation front, point taken. I'm not keen on 2k doing that stuff. But, it works for Dasher, so I think it is worthy of further study. My current thinking is that the editor should have a single command grammar that can be accessed by multiple alternative technologies: keyboard shortcuts, vi-like mnemonics, typed English like commands with autocompletion, gestures, pull-down menus, Dasher-like tree navigation and voice recognition. Some of these will benefit from stats, some won't. In the case of voice and Dasher, stats are essential. For some of the interfaces, they are less relevant. The command grammar will itself be a higher order data structure, and will need to adapt to the circumstances. In all, it looks like an interesting project!
OK, yes, I am keen on building the editor that I have always wanted. I'm not scared of the coding that will be necessary. I'm going to give it away free, and make sure it runs on all the major platforms, and write it in such a way as to allow people to hack their own modes, emacs-style.
I am quite keen to implement the internals in Haskell. Lazy evaluation gives a lot of what will be needed for free, quite efficiently. For a start, referential transparency will make efficiently implementing undo/redo completely trivial. A lazy list containing every version of the data structure that represents the document back to the point that the file was loaded would be trivial to implement, yet thanks to lazy evaluation would still be very space efficient.
I have quite an elegant design in mind, I think, so I don't want none of that messy other-people's-code cluttering up the place, nosiree! 8-)