[txmt-dev] Re: Implementing inline marks

Jacob Carlborg doob at me.com
Wed Aug 20 08:08:51 UTC 2014


On 19/08/14 12:12, Allan Odgaard wrote:

Thanks for the reply.

> 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?

Kind of. See below.

> 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?

I would actually need a std::vector to support multiple marks (error 
messages) per line. It's not completely uncommon for a compiler or lint 
tool to find several issues on a single line.

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

I imagine calling "mate" with multiple instance of the same flag to add 
multiple marks for a single line. Something like:

mate --line 10 --mark "error:foo" --mark "error:bar"

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

No problem.

> 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).

I would like to avoid hiding any of the user's code. I have basically 
already implemented the above, but putting the error message on the 
corresponding line. It's easy since I know the position and width of the 
line that is begin drawn and the width of the error message to be drawn. 
If the error message will cover the code I just move the drawing down a 
line. That's where the problem is, I don't know where the next line will 
be drawn and the drawing will possibly cover the next line.

I've been trying to solve this by passing the line width of the next 
line to the line I'm drawing. But I haven't figured out a way to do that.

Hmm, it might be easier to move the error message to the line above 
instead and just storing the previous line in the iteration and pass that.

Here is how the current behavior look like:

A simple error message: 
https://docs.google.com/file/d/0B7UtafxGD9vEWDdWbGY1cXBzX0U/edit

Wrapped error message: 
https://docs.google.com/file/d/0B7UtafxGD9vEVnlzaHg0TDdhd3c/edit

Wrapped error message covering the next line: 
https://docs.google.com/file/d/0B7UtafxGD9vESWNkakpwZVZHNnc/edit

-- 
/Jacob Carlborg



More information about the textmate-dev mailing list