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

[Alessandro Piras]

On 10/25/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> 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
> _______________________________________________
> vial-devel mailing list
> vial-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
> .
Ok :) just let me know what you decide to do, I'll take a look to
climacs if possible. Though yesterday I found climacs slow as hell,
but maybe It was something wrong with my system.