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