[txmt-dev] Re: Implementing inline marks

[Jacob Carlborg]

On 2014-08-30 13:33, Allan Odgaard wrote:

> Splitting a string on a delimiter is a fraction of the cost of actually
> drawing the strings, so there is no efficiency degradation to speak of
> here.

If that's the case, then that's fine by me.

> The tax I was talking about was about code complexity. The marks are
> dealt with in at least four places: the buffer that tracks how they move
> around, the document when we set marks for a document that isn’t open,
> extended attributes, from where we read/write bookmarks (but could also
> read other marks, for example when writing a backup file we probably
> should include all marks), and finally mate + rmate (of which there are
> 3 ports) which should send marks to TextMate via a socket.
>
> I would prefer not having to introduce the composite data type to all of
> the above code; using a string you can still put in multi-record data
> via a delimiter, and none of the code involved in the above would care.

None of that code has changed, so far. I kept the API completely 
backwards compatible. I added a new function that returns the vector. 
The old ones just return the first element in the vector.

> The marks_t (from buffer framework) associate marks with a buffer index.
> So yes, you can store for position 1:1 and 1:2.
>
> The document_t::add_mark actually takes a range and uses a multimap to
> store it (so multiple marks can be stored for same range). Though that
> API should be updated to how the buffer actually deals with marks.

I'll take closer look at that.

-- 
/Jacob Carlborg