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).
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
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
On Sun, 12 Jan 2014 20:16:26 +1100 Lex Trotman elextr@gmail.com wrote:
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).
Currently, single click or space positions you at the error/warning, and double click/enter positions and focuses the editor. That's not reproducible with a single link.
This would also mean that text can be copied from the view (a regular issue/request).
Right click -> Copy, Copy All. Though it may be better to have multiple selection for copying and use the cursor row for document positioning.
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.
"Easier" as in "doesn't require/support structured data"? :)
On 14 January 2014 04:55, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 12 Jan 2014 20:16:26 +1100 Lex Trotman elextr@gmail.com wrote:
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).
Currently, single click or space positions you at the error/warning, and double click/enter positions and focuses the editor. That's not reproducible with a single link.
Text tags (such as one causing a piece of text to be underlined in blue) can catch double clicks (event GDK_2_BUTTON_PRESS), just its not usually handled by apps. Or possibly with a different compiler window the paradigm could change with single click the link focussing the destination just like clicking links in browsers that open in new tabs. Show line (without focussing) could then be in the right mouse menu for the link.
This would also mean that text can be copied from the view (a regular issue/request).
Right click -> Copy, Copy All. Though it may be better to have multiple selection for copying and use the cursor row for document positioning.
Sorry I wasn't clear enough, yes, you can't copy part of a line or multiple lines.
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.
"Easier" as in "doesn't require/support structured data"? :)
Yep :)
(since the compiler/build output is sequential text and the only "structure" is lines)
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel