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