On 12 January 2014 11:17, Steven Blatnick steve8track@yahoo.com wrote:
My external-tools plugin takes file paths and opens them like a blue link in a webpage. The output is in a textarea-like instead of those table tree structures. Maybe if the compiler pane output to a text buffer like that, then maybe fonts would help. My plugin uses a monospaced font. (See github.com/sblatnick/geany-plugins external-tools branch and directory).
Havn't tried your plugin, but like the the idea of using gtk_text_view widgets with file/line/column references text marked as links (instead of the gtktreeview and click on the whole line we use now).
This would also mean that text can be copied from the view (a regular issue/request).
The text view (when its not user editable as we would use it) is also less complicated than the tree view, and IIUC faster to add lines to, another bugbear with the treeview.
Bigger change though.
Cheers Lex
Sorry if my terminology is off. I'm away from my computer.
Thanks, Steve
Lex Trotman elextr@gmail.com wrote:
On 11 January 2014 21:00, Thomas Martitz kugel@rockbox.org wrote:
Am 11.01.2014 10:35, schrieb Lex Trotman:
Hi All,
Two ideas for the Compiler tab open for consideration:
- Since both C/C++ compilers (g++, clang++) now output little ^
characters which are supposed to point to the place where they got confused, I suggest that the compiler tab use a (real) monospace font by default, so the ^ is in the intended place.
Not sure is the ^ really useful to us in geany? I'm not sure because clicking on the line moves the editor to that location anyway.
Yes clicking goes to the line, but doesn't indicate the column, which is what ^ does.
It would be better if it *did* go to the column but that needs focus forced to the editing widget to show the new cursor position. Focussing by clicking unfortunately makes the cursor go where you click :)
I just (belatedly) checked and there is PR #191 and patch #11 both purporting to handle column numbers, not sure of their status.
#191 is quite big but on quick glance I didn't actually see where the column was handled, and sf is so slow I ran out of patience looking for the patch 11.
- After a compile, the tab should be scrolled back to the top since,
AFAIK, most people clear up reported errors from the first to the last so they can identify and skip consequential errors caused by a prior compile error.
No, not to the top. If anything to the first error, but staying at the bottom is just fine. Compiler errors usually happen at the end so if you scroll to the top you might have to scroll all the way down again. This might be a lot to scroll for large projects where hundreds of files compiled successfully before the first error. FWIW, I usually fix compile errors in no specific order (usually I fix the first line, upwards from the bottom, where I can distinguish an error from a warning).
Yes agree, first error would be best.
Cheers Lex
Best regards. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel