[vial-devel] Re: What will break with flexichain

[Alessandro Piras]

---------- Forwarded message ----------
From: Alessandro Piras <laynor at gmail.com>
Date: Oct 24, 2006 5:41 PM
Subject: Re: What will break with flexichain
To: Brad Beveridge <brad.beveridge at gmail.com>


On 10/24/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> ....
> There is a grouping macro, WITH-UNDO-BLOCK that lets you group blocks
> of undos.  The saving of the cursor shouldn't be required - if you
> think about it, when you undo/redo you are playing back or unplaying
> keystrokes.  If you are undoing an insert of "hello there", you should
> delete 11 chars, and the point should be back before you inserted any
> text.

It works in most cases but in some don't...
try theese things:
insert "abcdefgh"
move to the "d" letter
delete "d" and "e" using the "x" command
now undo the changes, you'll see the cursor going to the end of the
line. instead of where it was before applying the x command.

The same behavior presents when you insert text between words, let's
say you have this line

pino pigna

you move the cursor between the 2 words, insert
" is", go to normal mode and press u to undo. The cursor will go at
the end of the line.

Same thing for the "c<motion>" command and such.
Good to know that there is already the macro for undo undo grouping !




> >
> <SNIP>
> > Tell me what do you think :)
> >
> I like it.  I think that right now I would like it most if you thought
> about issues like the "r" command, if we can get a framework that
> covers all those cases it will be really good in the long run.
I'll take a look to define pattern and think about a way to include
all forms of vim commands, maybe those like d3d too :)
I just hope it wont be too hard for a noob like me ^^

>Even
> though I just posted saying "let's not move to Flexichain right now",
> I'm leaning that way again.  I'll write up my thoughts to the list,
> but it basically boils down to the fact that being able to treat the
> buffer as a giant string has many advantages over the list of lines
> approach.
> The problem with changing out buffers right now is that we make lots
> of assumptions about the list of lines structure.  We basically need
> to change:
> buffer, cursor, register, search, colours, autocomplete, mode-lisp,
> regions, view, ncurses-io, undo
> But, each module will benefit greatly from being able to treate the
> buffer as a big string.
> Guess I have a lot of work ahead :)
>
> Cheers
> Brad
>
I thought you wanted to use a buffer made of a list of flexichains
(gap buffers), not just one gap buffer to handle our buffer..
reading the flexichains docs it seems that it's better to use a list
or a sequence of gap buffers rather than a big gap buffer.. In terms
of performance it seems. I don't know wich are the great benefits that
you are talking about though, so it could be that it's better having a
little less performance and a clerarer code, at least now :)

I think that we should put an abstraction layer also there, between
the buffer module and all those modules that now depend on the
implementation (the ones you listed above) ,if it makes sence, maybe
one day we'll want to change the buffer implementation again, and it
would be good not to change those modules again.

Tell me what you think, and if it is feasible to put an abstraction
layer also there :)

I forgot to say, I find the idea of using the emacs api a really good
one! Going to have a look at it soon.
__
Alessandro