---------- Forwarded message ---------- From: Alessandro Piras laynor@gmail.com Date: Oct 24, 2006 5:41 PM Subject: Re: What will break with flexichain To: Brad Beveridge brad.beveridge@gmail.com
On 10/24/06, Brad Beveridge brad.beveridge@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