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

[Brad Beveridge]

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

Logically, a Viper mode for Climacs would be the best solution to the
goal of "a Vi like editor in CL, for CL".  I still suffer from "not
invented here" as much as the next guy, so we will see how I go.
If I do a Viper mode (I think I'll still call it Vial mode), the goals would be:
1) Proper Vi feel - not the bastard child Viper feel
2) Slime integration (would have needed to be done anyway)
3) Build a McClim backend on top of ncurses.

Cheers
Brad