[txmt-dev] Re: Implementing inline marks

Allan Odgaard mailinglist at textmate.org
Sat Aug 30 11:33:14 UTC 2014


On 30 Aug 2014, at 12:05, Jacob Carlborg wrote:

> If a string is used and a delimiter to separate the messages, how 
> would I render that?

How you render it does not depend on how the value is stored (i.e. 
delimited string versus vector of strings).

You can introduce a convenience getter for the mark data type which 
returns a vector from splitting the string and your code wouldn’t know 
if the mark data type was backed by (string, vector of strings) or 
simply (string).

> Currently if there are multiple message for a single line each message 
> is drawn on its own line. That means I need to split the string on the 
> delimiter? I also need to do that every time because I don't know if 
> the string contains delimiters. Doesn't sound very efficient to me.

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.

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.

>> Marks can be set for a certain column on a line, so if we have 
>> messages
>> for different columns in the same line, we can already store that 
>> with
>> the simple position → string data type.
>
> They can do that already?

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.


More information about the textmate-dev mailing list