On 24/10/06, Alessandro Piras laynor@gmail.com wrote:

On 10/24/06, Alessandro Piras laynor@gmail.com wrote:

...

On 10/24/06, Brad Beveridge brad.beveridge@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