bug#3965: 23.1.50; compilation-mode gnu error regexp mismatching ant, irix, gcc-include

bug#3965: 23.1.50; compilation-mode gnu error regexp mismatching ant, irix, gcc-include

[Kevin Ryde]

Doing

    (setq compilation-error-regexp-alist '(gnu))

and visiting etc/compilation.txt shows some mismatched parts.

Under "ant"

        [jikes]  foo.java:3:5:7:9: blah blah

Under "irix"

    cfe: Warning 600: xfe.c: 170: Not in a conditional directive while ...
    /usr/lib/cmplrs/cc/cfe: Error: foo.c: 1: blah blah
    /usr/lib/cmplrs/cc/cfe: warning: foo.c: 1: blah blah

And under "gcc-include"

                     from test_clt.cc:1:

In each the match has the wrong part as the filename.  For example the
"ant" one matches "[jikes] foo.java".  With all patterns enabled
`next-error' offers those wrong matches instead of what the specific
patterns for those parts get -- I suppose because the gnu match is
earlier in the line.

Maybe the "ant" and "gcc-include" cases could be attacked by not
allowing leading whitespace.  The "omake" indentation hack might get in
the way there; but is its indentation arbitrary, or a fixed-ish amount?

My best idea for the irix ones would be to disallow ": " in the gnu
pattern filename part.  Other colons could be allowed for dos drive
letters or the occasional filename with a colon, but rate colon+space as
more likely to be a separator than a part of a name.  Mind you the gnu
pattern is already far too complicated for me to want to do anything to
it :-)



In GNU Emacs 23.1.50.4 (i586-pc-linux-gnu, GTK+ Version 2.16.4)
 of 2009-07-24 on blah.blah
configured using `configure  'CFLAGS=-O -g' '--prefix=/down/emacs/b/inst' '--with-x-toolkit=gtk''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t

bug#3965: acknowledged by developer (close 3965)

[Kevin Ryde]

reopen 3965
thanks

When working with gcc it will be usual to have both gnu and gcc-include
patterns active.  The way the gnu pattern mismatches the gcc-include
prevents following to the origin of an include error.

Processed: Re: bug#3965 acknowledged by developer (close 3965)

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> reopen 3965
bug#3965: 23.1.50; compilation-mode gnu error regexp mismatching ant, irix, gcc-include
bug reopened, originator not changed.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

Processed: close 3965

[Emacs bug Tracking System]

Processing commands for control@emacsbugs.donarmstrong.com:

> tags 3965 + notabug wontfix
bug#3965: 23.1.50; compilation-mode gnu error regexp mismatching ant, irix, gcc-include
There were no tags set.
Tags added: notabug, wontfix

> close 3965
bug#3965: 23.1.50; compilation-mode gnu error regexp mismatching ant, irix, gcc-include
'close' is deprecated; see http://emacsbugs.donarmstrong.com/Developer.html#closing.
bug closed, send any further explanations to Kevin Ryde <user42@zip.com.au>

>
End of message, stopping processing here.

Please contact me if you need assistance.

Don Armstrong
(administrator, Emacs bugs database)

bug#3965: 23.1.50; compilation-mode gnu error regexp mismatching ant, irix, gcc-include

[Chong Yidong]

> Doing
>
>     (setq compilation-error-regexp-alist '(gnu))
>
> and visiting etc/compilation.txt shows some mismatched parts.
>
> Under "ant" ...
> Under "irix"...
> And under "gcc-include"...
>
> With all patterns enabled `next-error' offers those wrong matches
> instead of what the specific patterns for those parts get -- I suppose
> because the gnu match is earlier in the line.

Correct.  That's the intended behavior.

> My best idea for the irix ones would be to disallow ": " in the gnu
> pattern filename part.  Other colons could be allowed for dos drive
> letters or the occasional filename with a colon, but rate colon+space as
> more likely to be a separator than a part of a name.  Mind you the gnu
> pattern is already far too complicated for me to want to do anything to
> it :-)

There's no point changing the gnu pattern just to handle these
additional patterns, which already have their own dedicated entries in
compilation-error-regexp-alist.

bug#3965: 23.1.50; compilation-mode gnu error regexp mismatching ant, irix, gcc-include

[Kevin Ryde]

Chong Yidong <cyd@stupidchicken.com> writes:
>
> There's no point changing the gnu pattern just to handle these
> additional patterns, which already have their own dedicated entries in
> compilation-error-regexp-alist.

Can't you have gcc-include and gnu at the same time?

I see in fact that mismatch is a regression.  In emacs 22 the gnu
pattern successfully keeps out of gcc-include's hair.

(If it is the "omake" hack then that bit may have a bit to answer for --
stopping the perl pattern working, making the gnu pattern work too much
... :-)