Re: Review request: javac in compilation-error-regexp-alist-alist

[Mattias Engdegård]

29 feb. 2020 kl. 00.02 skrev Filipp Gunbin <address@hidden>:

>> (Could I entice you into writing this regexp in rx? Not mandatory in
>> any way, but at least some of us who read it will thank you.)
> 
> I'm not experienced with it yet, but noted, will do later.

It's entirely optional. You could try the 'xr' package to help you translate.

> +    (javac
> +     ,(concat
> +       ;; line1
> +       "^\\(\\(?:[A-Za-z]:\\)?[^:\n]+\\):" ;file
> +       "\\([0-9]+\\): "                    ;line
> +       "\\(?:\\(?:error\\|\\(warning\\)\\): \\)?[^\n]*\n" ;type (optional) 
> and message

Thank you, much better. You may want to use '.' instead of '[^\n]'; they mean 
exactly the same thing.
There is also no need to match "error" specifically; "\\(warning: \\)?" 
suffices.

> +       ;; line2: source line containing error
> +       "[^\n]*\n"
> +       ;; line3: single "^" under error position in line2
> +       " *\\^\n")
> +     1 2
> +     ,(lambda ()
> +        (save-excursion
> +          (backward-char 2)             ; move back over "^\n"
> +          (current-column)))

There seems to be an off-by-one error in the column number; try it and you'll 
see. I think current-column is 0-based but Emacs expects a 1-based column from 
the compilation error matcher.

A minor bug (probably in compilation-mode) is that the mouse highlighting 
includes the first character of the line following the caret line. To avoid 
this, try replacing the final '\n' with '$'. As an extra benefit, the need for 
save-excursion and backward-char would go away.

This rule does present some performance concerns (perhaps unfounded): the first 
line, the "file:line: message" part, is likely to match many non-java messages. 
The entire next line is then matched regardless of contents, and the missing 
caret finally causes backtracking. I'm not sure how serious this is, or what 
can be done about it.