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

[Brad Beveridge]

On 24/10/06, Alessandro Piras <laynor at gmail.com> wrote:
> On 10/24/06, Alessandro Piras <laynor at gmail.com> wrote:
> > On 10/24/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> > > Pretty much all the functions in buffer.lisp and cursor.lisp will be
> > > preserved with the same semantics.  Any place that directly references
> > > lines-of buffer/cursor will need to change.
> > > I'll make changes to remove any and all references to those buffer or
> > > cursor members.
> > > So, feel free to do what you like, but please:
> > > Don't mess too much with cursor.lisp or buffer.lisp,
> > > don't directly access (lines-of cursor) or (lines-of buffer)
> > > Thanks :)
> > >
> > > Cheers
> > > Brad
> > >
> >
> > Ok, I'll keep working on commands and things. Though It would be a
> > good thing defining a more abstract interface for buffers, a sort of
> > "layer" that could be hacked inside that would be useful to:
> >
> > 1) handling some bugs of buffer implementation(s) we('ll) use
> > 2) Isolate theese hacks to a place
> > 3) Stabilizing a "language" used to write commands so they're
> > independent from the internals.
> > 4) Minimize the changes needed when internals have to change for some
> > reasons (we should only fix/modify the layer code, that's used from
> > many commands)
> >
> > When the buffer becomes stable, and it works well, we can tighten up
> > the interface, keeping commands' code the same,
> >
> > Tell me how does it sound :)
That sounds really good.  And I think that we already have the API
layed out - Emacs' internal API is actually really good :
http://www.delorie.com/gnu/docs/elisp-manual-21/elisp_toc.html
Trying to emulate the Emacs API has a few advantages
1) Don't need to invent a text-editing API
2) Already have good documentation, as long as we follow the behaviour
3) Low barrier to entry for people already familiar with that API.

> I forgot to say, we need also another type of command, different from
> motion, op or op-motion. With those three types it's hard (if
> possible) to code commands like "r", which is used a lot (it replace
> the char under the cursor with another, without entering insert mode),
> that take a character as an argument.
> Actually there are only a few commands that work that way (I only know
> of 3, "r" "f" "F"), but given the importance of replace-char it should
> be worth having a way to define them. also, maybe it's good if you're
> going to touch the buffer code, to think about a good interface for
> text replacing, so we could have a better implementation than
> removing/inserting the char, that maybe just does actual overwriting
> of text.
I decided that this should go to the list, for archive purposes.  Hope
you don't mind :)
You're right about the "r" command.  We should find all those
"special" cases, and make sure we can handle them.  "r" is something I
haven't considered yet, and I've been putting off replace mode :)

> Another thing to think about is a little annoyance in the
> current undo system. It works well, but some times not in the
> predictable way... I'll explain this to you better showing the cases I
> discovered, because it's better seeing than trying to figure it out
> from an explanation. The undo system we have just needs a few things
> more to work the way one would think, that are operation-grouping and
> cursor position saving.
> The good thing is that it can be easily (i guess) built on top of the
> current undo system. It would work this way:
>
> let's say we have a command that executes 3 basic operations (the J
> command is an example)
>
> op1
> op2
> op3
>
> we just need to wrap those in a group.
> also, we need to remember the cursor position before the command, so
> the thing we have to save is actually
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.

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