You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
This is my naive attempt at solving #1136. It works for me (not heavily tested yet), but I’m not sure if it’s a good idea. I would appreciate any feedback.
Geany’s message window is sort of detached from the editor. In general, it’s just lines of text that are not parsed or associated with the files in question until the user wants to navigate to one of them (although there are some exceptions).
Constrained by this design, I bolted on a cache of line number shifts. Actually two caches: one for the messages tab (line_shifts_msg) and one for the compiler tab (line_shifts_compiler). A cache is cleared when the user initiates a search/build (msgwindow_clear_tab), and then updated whenever the user adds/deletes lines in any open file (SCN_MODIFIED with a non-zero linesAdded), as long as any messages/errors are present. A cache is a hash table where keys are filenames and values are sequences of “at line, lines added” pairs (LineShift).
This of course means some overhead on mundane editing operations. Line numbers are requested from Scintilla, filename hashes are computed, arrays may need to be resized. Some of this overhead could be optimized out, but I’m not sure it’s worth it.
Also, this approach doesn’t handle undo very well. If there’s a compiler error on line 3, and I delete that entire line, and then undo the deletion, navigating to that error will now bring me to line 2 instead of 3, because the undo is understood as inserting an unrelated new line.
A possibly cleaner and/or more efficient approach might be to rely on Scintilla’s features such as line markers or indicators. That would probably require some revamp of the message window: lines would have to be parsed eagerly and associated with those Scintilla features as long as the corresponding file is open. I haven’t tried that approach.
https://github.com/geany/geany/pull/1481
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.