Hi,
Since it's not part of the message parsing, but affects the double clicking, I'll continue this thead a bit.
Currently, on a keypress / click on Compiler or Message line which contains valid filename and a too large line number (editor.c:9999), Geany does the following:
1. Opens the file, if not already open; that makes it's tab active. 2. Stores the previous file name and position, and the current file name with position -1 [our line # is too big] in the navqueue. 3. Attempts to seek to filename and position -1 and fails. 4. Does not focus editor on Enter / double click, since #3 failed.
(Of course, the steps are a bit different technically.)
What's wrong:
- The file tab becomes active for newly open files, but not for already open files. - An invalid position will be stored in the navqueue. Sometimes (when that position becomes current?), both <- and -> buttons will be disabled. - We reconginze the file, but neither switch to it's tab nor focus the editor.
My proposition:
1. Opens the file, if not already open; that makes it's tab active (same as before). 2. Stores the old filename and position. 2. Attempts to seek to the new position. 3. If successful [which implies that the file tab is activated], stores the new filename and position. 4. Otherwise, explicitly activates the file tab. 5. On Enter / double click, focuses the editor.
From Geany/plugin developers point of view, navqueue_goto_line()
will remain the same.
Alternatively, we can simply replace an invalid position with the current file position. The <- -> queue will be more consistent, but if a plugin wants to seek to editor.c:9999 and do something there, navqueue_goto_line() will "lie" that goto was successful.
So, please tell me what you think (and disregard my previous comments about position -1 in the "msgwin line and column" thread). Both variants are easy to implement.
-- E-gards: Jimmy