Re: [dev] Experimental editor

Hi

On Fri, Jun 10, 2011 at 12:05 AM, Connor Lane Smith <cls_AT_lubutu.com> wrote:
>
> 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:

Well, that's great. As soon as I have more free time I'll probably
join the IRC channel, maybe contribute some code if I get around the
code.

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

The lack of Shift+Control modifier is a serious bummer indeed.

>  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.

You probably won't unless things change a bit. Sandy is not a
"power-editor" right now. You could probably build a power editor
using sandy's code as a base, but it is not right now; and I doubt you
could build one while remaining mostly modeless.

>  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.

What do you mean by that? Is there an experimental way to view,
insert, change, delete text? I've read below about the multiple views
and all, is that one of the research-y ideas? Just curious.

> 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.

I like some of these. X seems sadly necessary.

> 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.

I dislike spawning several windows per process (it's confusing,
specially if several processes run concurrently), but then again you
need them if you want those multiple views. Please, do not split,
tab,etc your windows internally; not managing them sounds healthy
enough, but try not to gimp the thing too much.

> 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.

This is exactly what sandy does now, but sandy only has one windows, of course.

> 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.

I like the idea of structural regex, but I haven't used sam much. The
match buffer sounds a bit emacs-y for my taste. I doubt emacs has
something exactly like that; then again I am more of a vi(m) guy so
emacs is really a myth for me. And a scary one at it.

> 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.

I always disliked that vi's f/t/F/T commands did not wrap to the next line.

> 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.

Something like http://en.wikipedia.org/wiki/Rope_%28computer_science%29 I guess?

Best of luck with your project. It sounds different enough from sandy,
and we surely can exchange ideas, code, etc.

BR,
Rafa.
Received on Fri Jun 10 2011 - 09:54:33 CEST