[Geany-Devel] Compiler tab suggestions

[Lex Trotman]

On 12 January 2014 11:17, Steven Blatnick <steve8track at 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 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/20140112/d5d1027f/attachment.html>