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