On July 11, 2014 4:26:12 PM EEST, Charlie Kester <corky1...@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.
