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

Wed Oct 25 23:31:05 UTC 2006

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 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.
>
> 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 at 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.