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).<br><br>Sorry if my terminology is off. I'm away from my computer.<br><br>Thanks,<br>Steve<br><br>Lex Trotman <elextr@gmail.com> wrote:<br><br><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 11 January 2014 21:00, Thomas Martitz <span dir="ltr"><<a href="mailto:kugel@rockbox.org" target="_blank">kugel@rockbox.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 11.01.2014 10:35, schrieb Lex Trotman:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi All,<br>
<br>
Two ideas for the Compiler tab open for consideration:<br>
<br>
1) Since both C/C++ compilers (g++, clang++) now output little ^<br>
characters which are supposed to point to the place where they got<br>
confused, I suggest that the compiler tab use a (real) monospace font<br>
by default, so the ^ is in the intended place.<br>
<br>
</blockquote>
<br></div>
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.</blockquote><div><br></div><div>Yes clicking goes to the line, but doesn't indicate the column, which is what ^ does.</div>
<div><br></div><div>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 :)</div>
<div><br></div><div>I just (belatedly) checked and there is PR #191 and patch #11 both purporting to handle column numbers, not sure of their status.</div><div><br></div><div>#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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) After a compile, the tab should be scrolled back to the top since,<br>
AFAIK, most people clear up reported errors from the first to the last<br>
so they can identify and skip consequential errors caused by a prior<br>
compile error.<br>
<br>
</blockquote>
<br></div>
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).<br>
</blockquote><div><br></div><div>Yes agree, first error would be best.</div><div><br></div><div>Cheers</div><div>Lex</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Best regards.<br>
______________________________<u></u>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.geany.org" target="_blank">Devel@lists.geany.org</a><br>
<a href="https://lists.geany.org/cgi-bin/mailman/listinfo/devel" target="_blank">https://lists.geany.org/cgi-<u></u>bin/mailman/listinfo/devel</a><br>
</blockquote></div><br></div></div>