---------- 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
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
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.
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
On 10/25/06, Brad Beveridge brad.beveridge@gmail.com wrote:
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:
- Proper Vi feel - not the bastard child Viper feel
- Slime integration (would have needed to be done anyway)
- Build a McClim backend on top of ncurses.
Cheers Brad _______________________________________________ vial-devel mailing list vial-devel@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.
On 25/10/06, Alessandro Piras laynor@gmail.com wrote:
On 10/25/06, Brad Beveridge brad.beveridge@gmail.com wrote:
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:
- Proper Vi feel - not the bastard child Viper feel
- Slime integration (would have needed to be done anyway)
- Build a McClim backend on top of ncurses.
Cheers Brad _______________________________________________ vial-devel mailing list vial-devel@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.
I'm going to try to get vanilla Climacs going tonight to see how fast it is. What speed system do you have? Beach on IRC mentioned two reasons for Climacs slowness - excessive parsing of the Lisp code and possibly the McClim layer. Right now I'm not too concerned with speed, as long as it is usable - ie, keypresses don't feel like they take time to appear. I've posted to Climacs devel asking for hints on how to do the Vi style mappings.
Logically, adding a Vi mode to Climacs is the answer, but in reality I don't know yet.
Cheers Brad
On 10/25/06, Brad Beveridge brad.beveridge@gmail.com wrote:
On 25/10/06, Alessandro Piras laynor@gmail.com wrote:
On 10/25/06, Brad Beveridge brad.beveridge@gmail.com wrote:
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:
- Proper Vi feel - not the bastard child Viper feel
- Slime integration (would have needed to be done anyway)
- Build a McClim backend on top of ncurses.
Cheers Brad _______________________________________________ vial-devel mailing list vial-devel@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.
I'm going to try to get vanilla Climacs going tonight to see how fast it is. What speed system do you have? Beach on IRC mentioned two reasons for Climacs slowness - excessive parsing of the Lisp code and possibly the McClim layer. Right now I'm not too concerned with speed, as long as it is usable - ie, keypresses don't feel like they take time to appear. I've posted to Climacs devel asking for hints on how to do the Vi style mappings.
Logically, adding a Vi mode to Climacs is the answer, but in reality I don't know yet.
Cheers Brad _______________________________________________ vial-devel mailing list vial-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/vial-devel
I have an Intel centrino based machine, can't remember the MHz, I remember it's number, it's M725 if i remember right. It's a 1 year old laptop, with 512 MB Ram, fresh ubuntu dapper installation. The slowness wasn't so much on text inserting, it was on cursor moving, especially when hitting parentesis (parens matching). also it highlights parens displaying them in bold (it's surely customizable i guess though). When hitting parens, it seems it has to redisplay yhe whole buffer, it seems also that the lines "move" on the display when matching parens, making the line with the matched parens broader... I don't know why and hope it's something that has to do with my setup (I installed it via asdf-install though, so it should be a normal setup...), but I think that an editor should run on a 700 Mhz pc without any problem (emacs and vim do). Anyway, I noticed another strange thing, when I load files it gives some errors before loading, so maybe that slowness is something that has to do with those errors. Let me know about your experience with climacs, maybe it's just something wrong with my system.
Ps. gnu emacs runs superfast on my pc.
-
Alessandro Piras -
Brad Beveridge