Re: [dev] Experimental editor

On 10 June 2011 08:54, Rafa Garcia Gallego
<rafael.garcia.gallego_AT_gmail.com> wrote:
> 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.

Well, you can't exactly go crazy, but there are some things I'd like
to experiment with. The newest thing is probably adding interactivity
to structural regular expressions. There are also a lot of things
which do exist elsewhere but have never been brought together (we're
basically blending vi, emacs, sam, and archy); I think if we do this
well cool interactions will emerge.

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

I'd like window creation to be `fire and forget': we make it, that's
it. If for whatever reason you want to run multiple instances you can
always use tabbed, or just different tags, so you don't confuse them.
Each window will be a view, that's all.

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

So it is! I suppose the only difference is we'll show where the mark
is. I didn't realise sandy did this; emacs seems to just have the two.

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

Understandable. I'm happy with a match buffer on the basis that
matches are inherent to structural regular expressions, and they're
`first-class' in the editor. As such we won't have any accumulation of
view types, because regular expressions don't do very much. It just
seems strange, I suppose, that sam is built upon them, and yet if you
want to use them you have to use the command line interface. It seems
sensible that if you can run `x/re/' you can see them visually.

The match view wouldn't even do anything particularly special, just
instead of displaying a single buffer's 0,$ range it would display
various buffers' matched ranges. (For that reason I think we should
actually call it a match view, not a match buffer.) We could actually
make the behaviour part of the nature of views, in the sense that
views just display arbitrary ranges within buffers. I can't think of
another use case yet, but the symmetry is nice.

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

Similar, yes, though our approach will mean we can jump to an
arbitrary line or rune, rather than just a certain byte, in
logarithmic time.

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

Sounds good to me. :)

Thanks,
cls
Received on Fri Jun 10 2011 - 15:10:21 CEST