On Fri, Aug 5, 2011 at 1:32 PM Filip Gruszczyński gruszczy@gmail.com wrote:
Right now there are only two values in GeanyIndicators. There is a cool red underline for errors, but it would be even cooler to have a yellow wavy underline for warnings. Would that be possible for you to expose such value there?
ALL: while on that, woudn't it be a good thing to have underlining for FIF / Find Usage? There is an arrow indicator, but it's only for the clicked line, and the markers margin may be invisible. I'd prefer all matching lines marked, and there is a similar feature request [1]. Of course, it's easier to make it as Liviu suggested (a SCI_SETFOCUS is enough), but I find that confusing - looks like the editor is actually focused - and it's also for the clicked line only.
Filip: that yellow looks too bright to me as well. Of course, due to the different color schemes, nothing will look good for everyone. The right thing will be to make it configurable, see GEANY_INDICATOR_SEARCH in highlighting.c for an example.
ALL: unlike all other settings, our error underlining is a constant 0xFF0000, though I think the Japanese developers would prefer 0x00FF00. How about making it configurable?..
[1] http://sourceforge.net/tracker/?func=detail&aid=3386140&group_id=153...
On 12 August 2011 02:14, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, Aug 5, 2011 at 1:32 PM Filip Gruszczyński gruszczy@gmail.com wrote:
Right now there are only two values in GeanyIndicators. There is a cool red underline for errors, but it would be even cooler to have a yellow wavy underline for warnings. Would that be possible for you to expose such value there?
ALL: while on that, woudn't it be a good thing to have underlining for FIF / Find Usage? There is an arrow indicator, but it's only for the clicked line, and the markers margin may be invisible. I'd prefer all matching lines marked, and there is a similar feature request [1]. Of course, it's easier to make it as Liviu suggested (a SCI_SETFOCUS is enough), but I find that confusing - looks like the editor is actually focused - and it's also for the clicked line only.
Prefer selecting to underlining, there is enough crap in the edit window as is.
1. Selecting the text makes it work like normal find and
2. it makes focusing the edit window actually useful.
I didn't even notice that the edit window didn't focus since I always have to click where on the line I want the cursor, if the search text is selected then thats a likely useful position making focus useful, and then ordinary search can focus as well.
Lets not be inconsistent, lets not have some searches focus the edit window and some not, some select the text and some not.
Filip: that yellow looks too bright to me as well. Of course, due to the different color schemes, nothing will look good for everyone. The right thing will be to make it configurable, see GEANY_INDICATOR_SEARCH in highlighting.c for an example.
Good idea.
ALL: unlike all other settings, our error underlining is a constant 0xFF0000, though I think the Japanese developers would prefer 0x00FF00. How about making it configurable?..
Good idea.
Cheers Lex
On Fri, 12 Aug 2011 09:24:14 +1000 Lex Trotman elextr@gmail.com wrote:
ALL: while on that, woudn't it be a good thing to have underlining for FIF / Find Usage? There is an arrow indicator, [...] it's easier to make it as Liviu suggested (a SCI_SETFOCUS is enough), but I find that confusing - looks like the editor is actually focused
Prefer selecting to underlining, there is enough crap in the edit window as is.
It's hard to disagree with that... Since a filetypes styling entry has 4 fields, perhaps the 2nd as underline color, and the 4th as "on/off".
- Selecting the text makes it work like normal find and
Select the entire line?.. FIF / Find usage operate on lines, not words.
- it makes focusing the edit window actually useful.
I wrote this assuming that the change which focuses the edit window on double-clicking a message will be applied soon. SCI_SETFOCUS only makes the edit window appear as focused (caret, current line highlighted), but the message window retains focus, and when I tested it, that was confusing against the double-click.
[...]
- Selecting the text makes it work like normal find and
Select the entire line?.. FIF / Find usage operate on lines, not words.
Find usage knows the character position and size of the match, it just has to save it to be selected FIF will have to ask grep to mark the match(s) on the line and parse them for character positions to be selected
- it makes focusing the edit window actually useful.
I wrote this assuming that the change which focuses the edit window on double-clicking a message will be applied soon. SCI_SETFOCUS only makes the edit window appear as focused (caret, current line highlighted), but the message window retains focus, and when I tested it, that was confusing against the double-click.
What I meant is that focusing the window is not much use if the cursor position is going to be start of line, since I have to click in the window anyway to position the cursor (unless it happens that I want something close to the start). Selecting the match text has several advantages:
1. what matched is more visible so I can check I've got the right thing, the flashing caret is not real visible
2. the purpose of focusing the edit window is to allow me to start typing, the search string is more likely to be close to the place I need to edit than start of the line is
3. it is consistent with the behavior of the other searches
Cheers Lex
On Sat, 13 Aug 2011 10:13:19 +1000 Lex Trotman elextr@gmail.com wrote:
[...]
- Selecting the text makes it work like normal find and
Select the entire line?.. FIF / Find usage operate on lines, not words.
Find usage knows the character position and size of the match, it just has to save it to be selected
Yes... My mistake.
FIF will have to ask grep to mark the match(s) on the line and parse them for character positions to be selected
That can be a bit tricky. -o -b returns what we need, but the normal output is be lost, while --color=always will do, but the parsing is a bit more complex, and we should invoke grep with a GREP_COLORS prefix. Both assume GNU grep, of course.
What I meant is that focusing the window is not much use if the cursor position is going to be start of line, since I have to click in the window anyway to position the cursor (unless it happens that I want something close to the start). [...]
I get it now. FIF / Find Usage will certainly be better with line and column positioning, including Enter / double-click. Maybe implement that for the Compiler tab first? Looks easy, once I find where is the default error_regex. Huh.
[..]
FIF will have to ask grep to mark the match(s) on the line and parse them for character positions to be selected
That can be a bit tricky. -o -b returns what we need, but the normal output is be lost, while --color=always will do, but the parsing is a bit more complex, and we should invoke grep with a GREP_COLORS prefix. Both assume GNU grep, of course.
Yes, I was thinking of (ab)using the colour markings for this purpose, but we have already had problems with non-gnu grep, so maybe leave this until later.
What I meant is that focusing the window is not much use if the cursor position is going to be start of line, since I have to click in the window anyway to position the cursor (unless it happens that I want something close to the start). [...]
I get it now. FIF / Find Usage will certainly be better with line and column positioning, including Enter / double-click. Maybe implement that for the Compiler tab first? Looks easy, once I find where is the default error_regex. Huh.
Erm... looks easy? which compiler are you using that gives a column position?
GCC just gives a line number vaguely in the region that it sorta guesses is the error ;-D
Cheers Lex
Am 14.08.2011 06:27, schrieb Lex Trotman:
[..]
FIF will have to ask grep to mark the match(s) on the line and parse them for character positions to be selected
That can be a bit tricky. -o -b returns what we need, but the normal output is be lost, while --color=always will do, but the parsing is a bit more complex, and we should invoke grep with a GREP_COLORS prefix. Both assume GNU grep, of course.
Yes, I was thinking of (ab)using the colour markings for this purpose, but we have already had problems with non-gnu grep, so maybe leave this until later.
Perhaps just include gnu grep with geany if we're in fact depend on it?
What I meant is that focusing the window is not much use if the cursor position is going to be start of line, since I have to click in the window anyway to position the cursor (unless it happens that I want something close to the start). [...]
I get it now. FIF / Find Usage will certainly be better with line and column positioning, including Enter / double-click. Maybe implement that for the Compiler tab first? Looks easy, once I find where is the default error_regex. Huh.
Erm... looks easy? which compiler are you using that gives a column position?
GCC just gives a line number vaguely in the region that it sorta guesses is the error ;-D
My gcc gives columns as well: test.c: In function ‘main’: test.c:13:2: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘return’
Perhaps a more recent feature.
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[...]
Yes, I was thinking of (ab)using the colour markings for this purpose, but we have already had problems with non-gnu grep, so maybe leave this until later.
Perhaps just include gnu grep with geany if we're in fact depend on it?
IIRC the problem was to make sure it *didn't* depend on GNU grep only options or behavior.
[...]
Erm... looks easy? which compiler are you using that gives a column position?
GCC just gives a line number vaguely in the region that it sorta guesses is the error ;-D
My gcc gives columns as well: test.c: In function ‘main’: test.c:13:2: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘return’
Perhaps a more recent feature.
I'm using 4.4.3 (Ubuntu LTS version). The same error does not have a column number, only missing #includes do and they have a column no beyond the end of the line?? So could be a newer feature or is it an option?
And I still claim that (at least for C++) the line number is only approximate anyway :-)
Cheers Lex
Le 14/08/2011 10:12, Lex Trotman a écrit :
[...]
Yes, I was thinking of (ab)using the colour markings for this purpose, but we have already had problems with non-gnu grep, so maybe leave this until later.
Perhaps just include gnu grep with geany if we're in fact depend on it?
IIRC the problem was to make sure it *didn't* depend on GNU grep only options or behavior.
It's IMHO important not to depend on GNU grep, AFAIK even BSDs will not have it, at least by default (though maybe the implement some of the GNU grep's features, don't know).
[...]
Erm... looks easy? which compiler are you using that gives a column position?
GCC just gives a line number vaguely in the region that it sorta guesses is the error ;-D
My gcc gives columns as well: test.c: In function ‘main’: test.c:13:2: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘return’
Perhaps a more recent feature.
I'm using 4.4.3 (Ubuntu LTS version). The same error does not have a column number, only missing #includes do and they have a column no beyond the end of the line?? So could be a newer feature or is it an option?
-fshow-column
And I still claim that (at least for C++) the line number is only approximate anyway :-)
For C it's pretty relevant :)
It's IMHO important not to depend on GNU grep, AFAIK even BSDs will not have it, at least by default (though maybe the implement some of the GNU grep's features, don't know).
+1
[...]
-fshow-column
There is a documented -fno-show-column for the preprocessor only. Clang documents -fshow-column. The GCC mailing lists seem to suggest it exists, but until it is documented...
Maybe because which errors get columns is variable, until most have the feature its not official yet.
And I still claim that (at least for C++) the line number is only approximate anyway :-)
For C it's pretty relevant :)
Yes well, it doesn't have templates, but then macros and missing brackets confuse it too.
Cheers Lex
Le 15/08/2011 01:05, Lex Trotman a écrit :
It's IMHO important not to depend on GNU grep, AFAIK even BSDs will not have it, at least by default (though maybe the implement some of the GNU grep's features, don't know).
+1
[...]
-fshow-column
There is a documented -fno-show-column for the preprocessor only. Clang documents -fshow-column. The GCC mailing lists seem to suggest it exists, but until it is documented...
the man says that most options (I thing there is details about which ones do) have a "no-" variants, and IIRC that only the non-default is listed. AFAIK -fshow-column is the default since GGC 4.5, maybe you have checked a doc for GCC >= 4.5?
Maybe because which errors get columns is variable, until most have the feature its not official yet.
And I still claim that (at least for C++) the line number is only approximate anyway :-)
For C it's pretty relevant :)
Yes well, it doesn't have templates, but then macros and missing brackets confuse it too.
Well, when a macro is used and it's the expanded code that triggers the warning, yes the line is the one at which the macro is used without further details on where in the expanded macro the problem is.
Cheers, Colomban
the man says that most options (I thing there is details about which ones do) have a "no-" variants, and IIRC that only the non-default is listed. AFAIK -fshow-column is the default since GGC 4.5, maybe you have checked a doc for GCC >= 4.5?
Looked at 4.4 and 4.6 and still only documented as a preprocessor option?
Maybe because which errors get columns is variable, until most have the feature its not official yet.
[...]
Well, when a macro is used and it's the expanded code that triggers the warning, yes the line is the one at which the macro is used without further details on where in the expanded macro the problem is.
Yeah, same thing for C++ templates, and that is most of the standard library for C++.
Anyway if Dimitar wants to decode the column numbers in msgwin_parse_compiler_error_line() and use them to set the cursor thats fine, so long as column number is optional.
Personally I wouldn't bother to add column numbers to the fallback msgwindow.c/parse_compiler_error().
Cheers Lex
On Mon, 15 Aug 2011 10:19:26 +1000 Lex Trotman elextr@gmail.com wrote:
Anyway if Dimitar wants to decode the column numbers in msgwin_parse_compiler_error_line() and use them to set the cursor thats fine, so long as column number is optional.
Well you can always specify a two-match regular expression, such as "([^:]+):([0-9]+)" or "([^:]+):([0-9]+)[^A-Za-z]" for c++, and that will surely drop the column #, without the need for a special option.
Personally I wouldn't bother to add column numbers to the fallback msgwindow.c/parse_compiler_error().
Why not? There is only a single error_regex defined in the default configuration, everything else goes to the default parsing.
--
So here is the Compiler tab patch. Seeking to the exact column was a very nice extra when compiling Geany, even if I say so myself. :)
navqueue_goto_line[_col]() are written this way to preserve compatibility, since there may be a release in September. For the same reason, the Messages tab will have to wait.
Now the two questions, mentioned in navqueue.c:
How about supporting line number 0? process_build_output_line() does, and I, too, remember some old compilers emiting line 0.
How about leaving navqueue_goto_line_col() on pos == -1? According to Scintilla docs, it means that line - 1 is greater than the number of lines, and that's a wrong line # IMHO.
On 17 August 2011 04:11, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 15 Aug 2011 10:19:26 +1000 Lex Trotman elextr@gmail.com wrote:
Anyway if Dimitar wants to decode the column numbers in msgwin_parse_compiler_error_line() and use them to set the cursor thats fine, so long as column number is optional.
Well you can always specify a two-match regular expression, such as "([^:]+):([0-9]+)" or "([^:]+):([0-9]+)[^A-Za-z]" for c++, and that will surely drop the column #, without the need for a special option.
That was the idea, I just wanted to ensure that a two match regex doesn't cause errors.
Personally I wouldn't bother to add column numbers to the fallback msgwindow.c/parse_compiler_error().
Why not? There is only a single error_regex defined in the default configuration, everything else goes to the default parsing.
My reasons were:
1. save Dimitar some work (oh well too late :-)
2. from a quick inspection the only one of the defaults that would not parse with regexen is HTML since it has line and col but no filename, so there is no reason that columnated versions of the other compilers shouldn't go to regexes instead of hard coded, hard coded is bad (tm)
3. IIUC lack of regexii (as you can tell I don't know what the official plural of regex is :-) is because historically the hard coded approach existed first.
--
So here is the Compiler tab patch. Seeking to the exact column was a very nice extra when compiling Geany, even if I say so myself. :)
Comment on the patch:
Documentation says:
17 + whether the first or second match is purely digits.
but (if I read the patch correctly) it actually only checks the first and decides line [col] file or file line [col]
In filetypes.c/filetypes_parse_error_message()
64 + pmatch[2] = pmatch[3];
I don't think its necessarily legal or safe to assign one match to another, an opaque structure like regmatch_t might have pointers to internal data and this might result in double free or cause other problems.
The Geany convention is that symbols exported start with the prefix of the file they are exported from, and that words be separated by underlines, so strtopos should be utils_str_to_pos. That also makes it obvious that its a local function not a stdlib one.
In strtopos() it would be better to use strtoul(), no need to check l
= 0 and the (int)l == l s/b l <= G_MAXINT since the return is a gint.
navqueue_goto_line[_col]() are written this way to preserve compatibility, since there may be a release in September. For the same reason, the Messages tab will have to wait.
Now the two questions, mentioned in navqueue.c:
How about supporting line number 0? process_build_output_line() does, and I, too, remember some old compilers emiting line 0.
Sounds ok, line 0 == line 1?
How about leaving navqueue_goto_line_col() on pos == -1? According to Scintilla docs, it means that line - 1 is greater than the number of lines, and that's a wrong line # IMHO.
Agree.
Cheers Lex
On Wed, 17 Aug 2011 11:33:40 +1000 Lex Trotman elextr@gmail.com wrote:
- IIUC lack of regexii (as you can tell I don't know what the
official plural of regex is :-) is because historically the hard coded approach existed first.
Yes. After looking at the error_regex persing, default compiler parsing and default message parsing, I was not satisfied with any of them, and so will do something Lex-like: propose a global unified solution. After a few more days to think about it, that is.
Comment on the patch:
Documentation says:
17 + whether the first or second match is purely digits.
but (if I read the patch correctly) it actually only checks the first and decides line [col] file or file line [col]
"if (strtopos(match[1], line, TRUE) != NULL)" checks if the 2nd match is purely digits. line_idx is assigned before it for the match[line_idx] and possibly match[line_idx + 1] to be freed.
In filetypes.c/filetypes_parse_error_message()
64 + pmatch[2] = pmatch[3];
I don't think its necessarily legal or safe to assign one match to another, an opaque structure like regmatch_t might have pointers to internal data and this might result in double free or cause other problems.
regex_t is opaque, while regmatch_t is documented in regexec(1) as having only rm_so and rm_eo. Even if there are more, a regmatch_t is never freed or anything.
The Geany convention is that symbols exported start with the prefix of the file they are exported from, and that words be separated by underlines, so strtopos should be utils_str_to_pos. That also makes it obvious that its a local function not a stdlib one.
Hmm, yes. My bad.
In strtopos() it would be better to use strtoul(), no need to check l
= 0 and the (int)l == l s/b l <= G_MAXINT since the return is a gint.
Indeed... (gint) l == l must be checked though, unsigned long and gint have different ranges.
Now the two questions, mentioned in navqueue.c:
How about supporting line number 0? process_build_output_line() does, and I, too, remember some old compilers emiting line 0.
Sounds ok, line 0 == line 1?
Sure. My *cc at work emits line 0 sometimes...
How about leaving navqueue_goto_line_col() on pos == -1? According to Scintilla docs, it means that line - 1 is greater than the number of lines, and that's a wrong line # IMHO.
Agree.
On a 2nd thought, at this point we already switched to the file, so the filename was correct. Exiting navqueue_goto_line_col() with FALSE only prevents Enter and double click from focusing the editor, which is not very helpful. Addons/Tasks uses the return value, but doesn't seem like it really needs it. A void function will quickly solve the "what result to return if this or that argument is invalid or not entirely valid" question, but will have to wait until the release, so let's only add support for line = 0 for now.
I'll send a "-b" version tomorrow.
Yes. After looking at the error_regex persing, default compiler parsing and default message parsing, I was not satisfied with any of them, and so will do something Lex-like: propose a global unified solution. After a few more days to think about it, that is.
Yes, better to get it right slowly than wrong quickly :-)
Comment on the patch:
Documentation says:
17 + whether the first or second match is purely digits.
but (if I read the patch correctly) it actually only checks the first and decides line [col] file or file line [col]
"if (strtopos(match[1], line, TRUE) != NULL)" checks if the 2nd match is purely digits. line_idx is assigned before it for the match[line_idx] and possibly match[line_idx + 1] to be freed.
Ok.
In filetypes.c/filetypes_parse_error_message()
64 + pmatch[2] = pmatch[3];
I don't think its necessarily legal or safe to assign one match to another, an opaque structure like regmatch_t might have pointers to internal data and this might result in double free or cause other problems.
regex_t is opaque, while regmatch_t is documented in regexec(1) as having only rm_so and rm_eo. Even if there are more, a regmatch_t is never freed or anything.
Well you obviously get away with it because it isn't really opaque (to the compiler), but it is still bad practice to assign such structures unless it is documented safe.
The Geany convention is that symbols exported start with the prefix of the file they are exported from, and that words be separated by underlines, so strtopos should be utils_str_to_pos. That also makes it obvious that its a local function not a stdlib one.
Hmm, yes. My bad.
In strtopos() it would be better to use strtoul(), no need to check l
= 0 and the (int)l == l s/b l <= G_MAXINT since the return is a gint.
Indeed... (gint) l == l must be checked though, unsigned long and gint have different ranges.
Technically (gint)l == l is using implementation defined behavior, the standard says that the converting to a shorter signed type should give the same value if it fits, but if it doesn't fit, its implementation defined. On the other hand since the range of long is greater than or equal to the range in int which is what gint is, then the comparison to G_MAXINT is a correct way of doing it.
Now the two questions, mentioned in navqueue.c:
How about supporting line number 0? process_build_output_line() does, and I, too, remember some old compilers emiting line 0.
Sounds ok, line 0 == line 1?
Sure. My *cc at work emits line 0 sometimes...
I suppose thats as good as any for errors it doesn't have a line number for, so maybe we should use rand to pick a line number :-) oh, ok line 1.
[...]
On a 2nd thought, at this point we already switched to the file, so the filename was correct. Exiting navqueue_goto_line_col() with FALSE only prevents Enter and double click from focusing the editor, which is not very helpful. Addons/Tasks uses the return value, but doesn't seem like it really needs it. A void function will quickly solve the "what result to return if this or that argument is invalid or not entirely valid" question, but will have to wait until the release, so let's only add support for line = 0 for now.
Sounds fine.
Cheers Lex
On Thu, 18 Aug 2011 12:28:01 +1000 Lex Trotman elextr@gmail.com wrote:
pmatch[2] = pmatch[3];
Well you obviously get away with it because it isn't really opaque (to the compiler), but it is still bad practice to assign such structures unless it is documented safe.
Instead of attempting to imagine how a swallow copy may go wrong, I decided to just assign the two members. libc _can't_ access them for it's own purposes, because it doesn't know the lifetime of pmatch.
Technically (gint)l == l is using implementation defined behavior, the standard says that the converting to a shorter signed type should give the same value if it fits, but if it doesn't fit, its implementation defined.
Yes, if 'l' becomes unsigned long, such a check will be unreliable...
then the comparison to G_MAXINT is a correct way of doing it.
...which always works, so let's play it safe again. Thanks.
Hi,
There was no more comments in msgwindow double click, and my reasoning was partially wrong - a big line number may be a result of some lines being deleted by the user.
Because the patches affect the same code, I combined them here.
So, this "-c" version:
Parses an optional column # in the compiler messages. Handles line/column 0 as 1, and too big line/column as EOF/EOLN. Alters msgwin_goto_messages_file_line() not to pass invalid line # to navqueue_goto_line() if we know for sure that the file name is valid.
I tested the patch in the last few days. It seems fine, and is quite simple anyway.
Any other changes well have to wait after the 0.21 release.
Hi Dimitar,
Just to throw a spanner in the works :-D
I ran into this problem today:
In a project with C++ and python parts I happened to do a make with a Python file open, then all the c++ errors were not recognised.
In other words the standard Geany approach is only going to work for one filetype at a time, fair enough, but maybe choosing the filetype of the current file isn't appropriate sometimes, especially for make operations that may mix filetypes.
I am not sure there is a simple solution.
The complex (well maybe not so complex, but verbose) solution is a regex for each command. Then knowing your makefile lets you concoct a complex regex that supports more than one language. That also has the advantage of allowing me to support more than one compiler, I am starting to use clang as well as gcc for example.
There is no way I can think of to use the fallback msgwin.c/parse_compiler_error_line() though, since it will only work if it knows the filetype, and the only place it is going to get one of those is the current document, but thats what is wrong!
Any thoughts?
Cheers Lex
On 24 August 2011 03:40, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi,
There was no more comments in msgwindow double click, and my reasoning was partially wrong - a big line number may be a result of some lines being deleted by the user.
Because the patches affect the same code, I combined them here.
So, this "-c" version:
Parses an optional column # in the compiler messages. Handles line/column 0 as 1, and too big line/column as EOF/EOLN. Alters msgwin_goto_messages_file_line() not to pass invalid line # to navqueue_goto_line() if we know for sure that the file name is valid.
I tested the patch in the last few days. It seems fine, and is quite simple anyway.
Any other changes well have to wait after the 0.21 release.
-- E-gards: Jimmy
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 24 Aug 2011 16:44:35 +1000 Lex Trotman elextr@gmail.com wrote:
I ran into this problem today:
In a project with C++ and python parts I happened to do a make with a Python file open, then all the c++ errors were not recognised.
I know. See the "New messages/output parsing proposition" -> "Possible extensions".
On Sun, 14 Aug 2011 14:27:10 +1000 Lex Trotman elextr@gmail.com wrote:
I get it now. FIF / Find Usage will certainly be better with line and column positioning, including Enter / double-click. Maybe implement that for the Compiler tab first? Looks easy, once I find where is the default error_regex. Huh.
Erm... looks easy? which compiler are you using that gives a column position?
I meant that parsing the column will be easy. Though adding column support to the message window requires some work, and the plugins ABI must be changed. Only a few plugins use msgwin_msg_add*, but the full patch will have to wait after out september release.
GCC just gives a line number vaguely in the region that it sorta guesses is the error ;-D
It emits a column number pretty often on my system. Sometimes even close to the actual error. :)