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

[Alessandro Piras]

On 10/25/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> 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
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
>

Mh, It sounds like a viper like project for climacs, is this the case?
I'll try climacs a little if it's the case, just to see how it performs.