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:

1) 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.



2) 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