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!
