[txmt-dev] Re: Implementing inline marks

[Allan Odgaard]

On 29 May 2014, at 14:30, Jacob Carlborg wrote:

> […] I have changed the implementation of drawing a background color 
> on a line to use marks related functions [2] in the buffer framework 
> as suggested in the previously mentioned thread. The next step is I 
> need to support displaying marks data (error messages). For that I 
> have two questions:
>
> 1. I need to store the data (text) somewhere. Should I extend the 
> "marks_t" [3] type to support storing some additional data or create a 
> new separate type that behave like "marks_t"?
>
> Actually, I've already tried and changed the implementation to store a 
> std::vector<std::string> in the indexed map [4] instead of a 
> std::string. The existing API in "marks_t" is complete backwards 
> compatible and I've added new functions to return a 
> std::vector<std::string> instead of a std::string. It works, but I 
> don't know if it's a good idea.

It seems I went in two different directions since the mark_t type in 
document.h defines both `type` and `info` (strings) where `info` is what 
you are missing in `buffer_t`’s `marks_t` metadata, right?

I think I was considering simply merging the two fields with a colon, so 
you could set a mark like: “error:unknown identifier” which would 
not require updating any structs and for marks without metadata, there 
would be no extra overhead (of empty std::string or std::vector).

Would that be sufficient?

This would also be consistent with how we envision calling this from 
mate.

> 2. When it comes to drawing the marks data I think there's two 
> options:
>
> A. Add the data as a text node
> B. Draw it separately on a line
>
> With A I don't know how well it works to basically have two separate 
> text strings on the same line. One that will be draw from the left 
> side (the code) and one that will be drawn from the right side (the 
> mark data).
>
> With B there's the issue with line wrapping. Usually there's plenty of 
> space to the right of the text on a single line, because most 
> developers try to keep their code within 80 columns (or similar). But 
> if the main view gets too small, either by the window getting too 
> small (or the output window is place inside the main window to the 
> right) the mark data need to be able to wrap to not cover up the code 
> in the main view.
>
> I have already implemented option B with support for wrapping, but 
> only for the same line, i.e. if the mark data would cover the code on 
> the line which the mark is attached to, it will be rendered on the 
> next line. But with the current implementation it will still cover 
> code on the next line (if there is any). I'm wondering if I'm 
> reimplementing some of TextMate's line wrapping by choosing option B.

I am not sure what to recommend here. And partly that is why I kept this 
reply pending for so long. Sorry about that.

The layout data structure is complex, mainly because operations on it 
must have good time complexity. For this reason, I would generally avoid 
touching it, if it can be avoided (i.e. your option B). For example 
selections are drawn separately because the same scalability 
requirements are normally not required [1].

Though as you mention, the overlaid text should not overlap the user’s 
code, so some sort of integration is desired. Although, we could draw it 
below the line and to the right (in a box), that way, it could overlap 
the line below, but since it’s pointing to an error/warning above, 
that should be less of an issue — could make the box closable, or 
maybe even allow it to be moved (it would scroll with the text, so sort 
of a movable anchoring point, although the implementation details of 
that are not obvious, mainly how the anchors should adjust to text 
edits).

[1] I have since received several performance bug reports from people 
with thousands of discontinuous selections.