[Geany-Devel] Compiler tab suggestions

[Steven Blatnick]

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 at gmail.com> wrote:

>On 11 January 2014 21:00, Thomas Martitz <kugel at 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 at lists.geany.org
>> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>>
>
>_______________________________________________
>Devel mailing list
>Devel at lists.geany.org
>https://lists.geany.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20140111/1135c149/attachment-0001.html>