[txmt-dev] Re: Implementing inline marks
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
[txmt-dev] Re: Implementing inline marks
On 30 Aug 2014, at 12:05, Jacob Carlborg wrote: If a string is used and a delimiter to separate the messages, how would I render that? How you render it does not depend on how the value is stored (i.e. delimited string versus vector of strings). You can introduce a convenience getter for the mark data type which returns a vector from splitting the string and your code wouldn’t know if the mark data type was backed by (string, vector of strings) or simply (string). Currently if there are multiple message for a single line each message is drawn on its own line. That means I need to split the string on the delimiter? I also need to do that every time because I don't know if the string contains delimiters. Doesn't sound very efficient to me. 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. 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. Marks can be set for a certain column on a line, so if we have messages for different columns in the same line, we can already store that with the simple position → string data type. They can do that already? 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. ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Implementing inline marks
On 2014-08-30 08:22, Allan Odgaard wrote: I’m not too fond of this because I don’t see a big need for multiple marks for the same position, and by going with position → (string, vector of strings) we tax everything with a more complex data type, rather than tax the special case (which could store multiple messages for the same position using a delimiter like the ASCII record or unit seperator). If a string is used and a delimiter to separate the messages, how would I render that? Currently if there are multiple message for a single line each message is drawn on its own line. That means I need to split the string on the delimiter? I also need to do that every time because I don't know if the string contains delimiters. Doesn't sound very efficient to me. Marks can be set for a certain column on a line, so if we have messages for different columns in the same line, we can already store that with the simple position → string data type. They can do that already? -- /Jacob Carlborg ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Implementing inline marks
On 20 Aug 2014, at 10:08, Jacob Carlborg wrote: […] merging the two fields with a colon, so you could set a mark like: “error:unknown identifier” […] 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. I’m not too fond of this because I don’t see a big need for multiple marks for the same position, and by going with position → (string, vector of strings) we tax everything with a more complex data type, rather than tax the special case (which could store multiple messages for the same position using a delimiter like the ASCII record or unit seperator). Marks can be set for a certain column on a line, so if we have messages for different columns in the same line, we can already store that with the simple position → string data type. ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Implementing inline marks
On 20/08/14 10:08, Jacob Carlborg wrote: Here is how the current behavior look like: And here's the implementation: https://github.com/jacob-carlborg/textmate/compare/textmate:master...c18bd359a220f028eab8d119c1b2581c9f550455 -- /Jacob Carlborg ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Implementing inline marks
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
[txmt-dev] Re: Implementing inline marks
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 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 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
[txmt-dev] Re: Implementing inline marks
On 2014-07-09 12:29, Allan Odgaard wrote: Sorry, your letter was a bit open-ended so I just flagged it as “look at it later”, I’ll push it up the list. Thanks. -- /Jacob Carlborg ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Implementing inline marks
On 7 Jul 2014, at 9:35, Jacob Carlborg wrote: On 29/05/14 14:30, Jacob Carlborg wrote: This is a followup on the "Setting the background color of a specific line" [1] thread. Allan, any comments on this? Sorry, your letter was a bit open-ended so I just flagged it as “look at it later”, I’ll push it up the list. ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Implementing inline marks
On 29/05/14 14:30, Jacob Carlborg wrote: This is a followup on the "Setting the background color of a specific line" [1] thread. Allan, any comments on this? -- /Jacob Carlborg ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Implementing inline marks
Hi Jacob, This sounds like cool work! I can't comment on the questions you raise. But please be sure to make that system flexible enough to also support a column. Many languages provide columnar information along with the error. In fact some languages even support a range and 1 or more "fix it" suggestions. It would be cool to be able to support that in Xcode. Thanks Gerd On May 29, 2014, at 7:30 AM, Jacob Carlborg wrote: > This is a followup on the "Setting the background color of a specific line" > [1] thread. As I said later in that thread I'm now working on implementing > inline marks (errors, warnings, etc). The way I imagined this to work like is > how it works in Xcode. The "mate" command will have a flag to set a mark and > data (text string) on a particular line (as discussed in the thread [1]). > This will be shown in TextMate by it drawing a background color on all lines > with a mark and the mark's data will be drawn on the same line but to the > right (where there's usually extra space). > > 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 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 instead of a std::string. It > works, but I don't know if it's a good idea. > > 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. > > [1] > http://textmate.1073791.n5.nabble.com/txmt-dev-Setting-the-background-color-of-a-specific-line-td27632.html > > [2] > https://github.com/textmate/textmate/blob/master/Frameworks/buffer/src/buffer.h#L130-L136 > > [3] > https://github.com/textmate/textmate/blob/master/Frameworks/buffer/src/meta_data.h#L38 > > [4] > https://github.com/textmate/textmate/blob/master/Frameworks/buffer/src/meta_data.h#L53 > > -- > /Jacob Carlborg > > ___ > textmate-dev mailing list > textmate-dev@lists.macromates.com > http://lists.macromates.com/listinfo/textmate-dev ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
