compilerbitch: That's me, that is! (Default)
[personal profile] 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.

(no subject)

Date: 2003-08-06 11:05 pm (UTC)
From: [identity profile] compilerbitch.livejournal.com
I was kind-of expecting the existing Dasher code to be a bit too specific. What I had in mind was a grammar implemented as some kind of higher order data structure (probably in a lazy functional language like Haskell), visualised by a front end (probably in C++) that can provide access to the grammar in multiple ways. For example, the same structure could be visualised by cascading pull down/pop up menus, something Dasher-like, voice, auto completion, content-sensitive 'palette' panes that allow keywords/variables/code templates to be inserted with a single click, etc. This approach has the same kind of qualitative advantages that are achieved by separating the front and back halves of a compiler. I think there is a strong case for building a new editor -- it's hard to see how this kind of architecture could be retrofitted to an existing editor like emacs or jEdit.

Another Dasher-related question for you. One issue I can see with the existing Dasher design is that the dasher interface is in a separate, fixed split pane. Leo Dearden and I were speculating that floating this pane 'over' the source code might be better, maybe even using partial transparency so you can still read what is under it. Our reason for thinking this was partly because it would very significantly reduce the amount of mouse movement needed when swapping between Dasher and selecting text or positioning the cursor. Also, it would allow nearly all of the screen to be taken up with code -- something that programmers typically find extremely important. Have you experimented with that kind of design at all?

We were also thinking about the possibility of building the interface in OpenGL, because this would immediately open up access to the extreme performance of modern graphics cards, whilst also making things like antialiasing and transparency relatively easy to implement. Also, it should open up interesting ways to visualise and navigate code graphically, but that's getting away from the initial intentions somewhat.

I'm going to be away for a week now, but would definitely like to discuss this further when I get back.

(no subject)

Date: 2003-08-07 06:21 am (UTC)
From: [identity profile] mjg59.livejournal.com
It certainly sounds interesting, and it would be good to see what you come up with. As far as the transparency goes, the MacOS X version has something pretty much as you're suggesting (screenshot (http://vavatch.codon.org.uk/~mjg59/DasherMacOSX.jpg)) - the Windows client would also be amenable to this sort of thing, but we start running into trouble under X11 due to its complete lack of implementation of transparency (and various other useful things, but...). The current X11 code lets you shring the edit box to nothing and then enter text directly into another window if you have recent enough (CVS) GNOME accessibility code.

Using OpenGL for the interface code would be fun, but at the moment I'm doing most of my development work on my laptop which has a quite desperately poor 2D-only graphics chip. When I get my desktop sorted again, I'll take a look at it.

Please do get in touch when you're back - I'm away next week, but around after that.

Profile

compilerbitch: That's me, that is! (Default)
compilerbitch

January 2016

S M T W T F S
     12
3 45 6789
10111213 141516
17181920212223
24 252627282930
31      
Page generated Sep. 6th, 2025 07:09 pm

Style Credit

Expand Cut Tags

No cut tags