On 11/01/2014 12:28, Lex Trotman wrote:
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.
PR 191 is pretty much good to go. I might have missed a thing or two in the makefiles. The column numbers are handled once when the error message is parsed, and again when actually jumping to that location. The rest of the code is agnostic of column numbers and many other details, since they're all encapsulated in the new GeanyFileLocation type (which, while a little big, is mostly boilerplate). This allows us to easily deal with different kinds of "column numbers" that different tools produce, be they character numbers, actual column numbers or byte offsets of some kind.
I took a quick glance at patch 11 (which is older than mine and I was unaware of. I didn't mean to be a dick, Dimitar :) It's not as comprehensive and a bit problematic. It treats compiler "column numbers" as if they're actually column numbers, while in reality they almost never are. Which means that it's not going to work right as soon as the code contains tabs or multibyte characters. Since it doesn't use named capture groups for the message parsing, it's a little less flexible in the type of messages it can parse, and it also cannot handle different styles of error messages in the same regex. The example given in the documentation is actually not going to work when the column number is missing.