Re: [dev] [sandy] [PATCH] VIM key bindings.

From: Maxime Coste <frrrwww_AT_gmail.com>
Date: Fri, 11 Jul 2014 09:48:39 +0100

On Thu, Jul 10, 2014 at 03:59:01PM -0700, Charlie Kester wrote:
> On Thu 10 Jul 2014 at 15:46:13 PDT Dimitris Papastamos wrote:
> >On Fri, Jul 11, 2014 at 01:43:16AM +0300, Dimitris Zervas wrote:
> >>First of all, we haven't even agree in which data structure will we use.
> >>Buffer gap, piece table, or pointer array?
> >
> >If you want to tackle this, I'd go with whatever approach you feel most
> >comfortable with.
> >
> >Try to keep it simple, maybe separate out the data structure implementation.
>
> I agree. Start by identifying the editing operations that the data
> structure must support, no matter how it is implemented. Those
> operations will form the API for your data engine, and no other part of
> the editor should be written in a way that cares about the internals of
> that engine.

Basically you can work with a single operation: Replace range

replace_buffer_range(buffer, start, end, new_content);

This provides insert (start == end), erase (new_content is empty),
and replace without needing to do erase then insert.

I did discover that a little late, and so Kakoune does not rely on it
(it uses insert and erase as primitive operations), but I wish I did.
I might take some time to change things to use that one day.

For arrays resize, it is blazingly fast on modern cpus, you'd have to
use very, very big files so that using a linked list of lines would
get better, even if the complexity says otherwise.

Lastly, an array of lines is actually a sort of rope, which use its
specialized knowledge of the target text (code, so very line/column
oriented) to simplify its implementation and keep good performances.

I use that in Kakoune, and the regexes can span multiple lines without
problems, so this really is not something to worry about. Note that
I keep the '\n' in stored lines in order to keep that simple.

Cheers,

Maxime.
Received on Fri Jul 11 2014 - 10:48:39 CEST

This archive was generated by hypermail 2.3.0 : Fri Jul 11 2014 - 10:48:08 CEST