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