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

[Brad Beveridge]

On 24/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> ---------- 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.
> __

Continuing with the "steal it" motif, I am thinking about stealing
even more from Climacs.  The plan as it stands is to try and use
Climacs files wholesale, including the buffer protocol, the undo
protocol, etc.
I don't fully know how to do it yet, but at least for a while you will
probably need a Climacs code tree hanging around.
http://www.cliki.net/Climacs
dept-info.labri.fr/~strandh/climacs-internals.pdf
dept-info.labri.fr/~strandh/climacs-user.pdf

Basically the only parts of Vial that we can keep are the key
handling.  This is probably almost a total rewrite.
Sorry to have announced Vial and then immediately take a different
tack.  If truth be told, I should have done this before I publicly
announced - but it took going public for a third party to hit me with
a cluestick.

Cheers
Brad