On 25/10/06, Alessandro Piras laynor@gmail.com wrote:
On 10/25/06, Brad Beveridge brad.beveridge@gmail.com wrote:
On 24/10/06, Alessandro Piras laynor@gmail.com wrote:
---------- 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. __
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@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