[dev] Experimental editor

Hey all,

I'd like to include those of you who aren't in IRC in the discussion
we're having wrt writing a new text editor. We do already have Sandy
of course, and I think Rafa is doing a great job, but there are a
couple of reasons why I don't think it will for me replace Vi:

 1. Curses: it has its benefits, but for a modeless editor it is
    extremely restrictive.

 2. Speed: maybe I've just not warmed up to it yet, but I don't feel
    like I'll get as fast with Sandy as I am with Vi.

 3. It's not experimental. In some ways that's a good thing. My project,
    however, will be very experimental. Perhaps too much. It'll teach us
    things.

My plan, then, is to write an editor for X, which although
(almost-)modeless, is extremely fast to use. (I say `almost' because
search, for instance, is a mode, but is at the users' locus of
attention. I may also make `Escape' an optional command/insert mode
switch.) Let me be clear, this will not be a tiny minimalist editor;
that is already covered by ed. This will fill the same place as vi: it
may be a little larger, but damn is it fast.

It's difficult with a project like this to know where to start, so
I'll just explain the idea and hope I don't leave out anything
important. Feel free to contribute ideas; not much code has been
written, yet (expect this to be a long-term project).

So, we have a bunch of windows, each of which represents a buffer.
Multiple windows can display a single buffer, if you clone (or
`zerox') it, in which case you can edit in both windows
simultaneously, which is nice when you're dealing with big files like
`dwm.c'. Importantly, we just make windows, we don't manage them: you
can use dwm, or embed them in tabbed, or whatever; we don't care.

Each window maintains three marks within the buffer, `cursor',
`select', and `mark'. The `cursor' is your current position in the
buffer, `select' defines the extent of your current selection, and
`mark' is a separate subtle cursor-like point elsewhere in the buffer
which acts as a useful kind of pivot. For instance, when you
(incrementally) search it sets `mark' to your original location and
then hops through the buffer, so you can always return to where you
were in a keypress.

The editor uses interactive structural regular expressions, somewhat
like sam, only with more visual support. Say you run the command
`x/re/'; a special `match' buffer will open containing the matching
lines and line numbers (and in the case of X & Y, their file names
too), allowing you to jump to those locations. You can then edit and
run commands on these matches (including filtering) and the buffer(s)
will be updated accordingly.

In Vi I use `f' and `F' a lot. That is, I jump within lines so I don't
have to bother crawling with the cursor or reaching for the mouse.
This is faster than using `/' because you don't have to press enter
(surprisingly this has a big difference). In a similar fashion, this
editor will (as well as normal search) have a `leap' quasimode (cf.
Jef Raskin) which lets you search just by holding Meta, and to exit
search mode you just release. This is faster to use, doesn't spam your
search history, and means we can stop matching at the first match,
whereas with full search we'd highlight all matches in the scrollbar.

That's pretty much an overview of the core idea. If anyone has any
ideas I'd like to hear them. Right now we're mostly brainstorming,
though rransom is writing a monoid which will let us use B-trees for
out internal buffer data structure. Simply put, it will make buffers
ridiculously fast: linear regexp matching, constant or logarithmic
everything else. So then I'll get to work on the editor proper.

("I think we're gonna confuse the ocean waves with all this typing.")

Thanks,
cls
Received on Fri Jun 10 2011 - 00:05:27 CEST