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

From: Dimitris Zervas <dzervas_AT_dzervas.gr>
Date: Fri, 11 Jul 2014 16:35:50 +0300

On July 11, 2014 4:26:12 PM EEST, Charlie Kester <corky1951_AT_comcast.net> wrote:
>On Fri 11 Jul 2014 at 06:06:39 PDT Charlie Kester wrote:
>>On Fri 11 Jul 2014 at 01:48:39 PDT Maxime Coste wrote:
>>>On Thu, Jul 10, 2014 at 03:59:01PM -0700, Charlie Kester wrote:
>>>>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.
>>
>>Very cool!
>>
>>But you'll need a couple of other basic operations too:
>>
>>* read the text within a given range
>>
>>* search, i.e. set 'start' and 'end' given a regex. (You might want
>to
>> have this return a set of ranges rather than just one.)
>>
>
>On second thought, if you have buffer_read(), you don't need to
>implement search using any knowledge of the data engine's internals.
>The situation is analogous to working with files, where the operating
>system is hiding implementation details like inodes and disk blocks.
>In
>both cases, it's easier to work with an abstract data stream.
>
>Sorry, doing some preliminary design thinking out loud!
Well, it's good to have an idea of what am I going to do, after this patch set.

I was thinking of a super easy implementation, nearly without a buffer.
Spit the chars to the screen and replace characters on the fly.
When a buffer is needed (search/save/etc.), read the screen.
This would gave a dramatic boost in regular operations, but a slowdown to the operations that need a buffer.
Received on Fri Jul 11 2014 - 15:35:50 CEST

This archive was generated by hypermail 2.3.0 : Fri Jul 11 2014 - 15:48:03 CEST