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.
_______________________________________________
textmate-dev mailing list
textmate-dev@lists.macromates.com
http://lists.macromates.com/listinfo/textmate-dev
