subtle problem of font-lock in *compilation* buffer

subtle problem of font-lock in *compilation* buffer

[Kenichi Handa]

In *compilation* buffer, font-lock thinks that this kind of
line is an error message:

/bin/sh ../libtool --tag=CC --mode=link gcc  -g -Wall --pedantic   -o libm17n-core.la -rpath /usr/local/lib -export-dynamic -version-info 1:0:1 character.lo chartab.lo plist.lo m17n-core.lo mtext.lo symbol.lo textprop.lo mtext-lbrk.lo mtext-wseg.lo -L/usr/lib -lxml2 -lz -lpthread -lm -L/usr/local/lib -lthai   -ldl 

That is perhaps because of "1:0:1".

---
Kenichi Handa
handa@m17n.org

Re: subtle problem of font-lock in *compilation* buffer

[Chong Yidong]

Kenichi Handa <handa@m17n.org> writes:

> In *compilation* buffer, font-lock thinks that this kind of
> line is an error message:
>
> /bin/sh ../libtool --tag=CC --mode=link gcc  -g -Wall --pedantic   -o libm17n-core.la -rpath /usr/local/lib -export-dynamic -version-info 1:0:1 character.lo chartab.lo plist.lo m17n-core.lo mtext.lo symbol.lo textprop.lo mtext-lbrk.lo mtext-wseg.lo -L/usr/lib -lxml2 -lz -lpthread -lm -L/usr/local/lib -lthai   -ldl 
>
> That is perhaps because of "1:0:1".

How can the compilation font-lock pattern distinguish this from a
legitimate error message?  Maybe this is too hard to solve (and it
seems to be a fairly uncommon situation).

Re: subtle problem of font-lock in *compilation* buffer

[Kenichi Handa]

In article <87ejujxg42.fsf@furball.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:

> Kenichi Handa <handa@m17n.org> writes:
> > In *compilation* buffer, font-lock thinks that this kind of
> > line is an error message:
> >
> > /bin/sh ../libtool --tag=CC --mode=link gcc  -g -Wall --pedantic   -o libm17n-core.la -rpath /usr/local/lib -export-dynamic -version-info 1:0:1 character.lo chartab.lo plist.lo m17n-core.lo mtext.lo symbol.lo textprop.lo mtext-lbrk.lo mtext-wseg.lo -L/usr/lib -lxml2 -lz -lpthread -lm -L/usr/local/lib -lthai   -ldl 
> >
> > That is perhaps because of "1:0:1".

> How can the compilation font-lock pattern distinguish this from a
> legitimate error message?  Maybe this is too hard to solve (and it
> seems to be a fairly uncommon situation).

I don't know whqether it's uncommon or not, but if a packages uses
libtool with "-version-info M:N:L" argument, the above line
appears.  It may be too ad hoc but we can tell font-lock
that a line matching with the regexp "-version-info [0-9]"
is not an error message (if font-lock accepts such a
request).  Or, more generally, we may be able tell that a
line matching with "^/bin/sh " is not an error message.

---
Kenichi Handa
handa@m17n.org

Re: subtle problem of font-lock in *compilation* buffer

[Richard Stallman]

    > /bin/sh ../libtool --tag=CC --mode=link gcc  -g -Wall --pedantic   -o libm17n-core.la -rpath /usr/local/lib -export-dynamic -version-info 1:0:1 character.lo chartab.lo plist.lo m17n-core.lo mtext.lo symbol.lo textprop.lo mtext-lbrk.lo mtext-wseg.lo -L/usr/lib -lxml2 -lz -lpthread -lm -L/usr/local/lib -lthai   -ldl 
    >
    > That is perhaps because of "1:0:1".

    How can the compilation font-lock pattern distinguish this from a
    legitimate error message?

How about by the spaces in the "file name"?

Re: subtle problem of font-lock in *compilation* buffer

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     > That is perhaps because of "1:0:1".
>
>     How can the compilation font-lock pattern distinguish this from a
>     legitimate error message?
>
> How about by the spaces in the "file name"?

It would wrongly reject compilation messages for file names containing
spaces.


Kenichi Handa <handa@m17n.org> writes:

> I don't know whqether it's uncommon or not, but if a packages uses
> libtool with "-version-info M:N:L" argument, the above line
> appears.  It may be too ad hoc but we can tell font-lock
> that a line matching with the regexp "-version-info [0-9]"
> is not an error message (if font-lock accepts such a
> request).

I don't see a straightforward way of doing this, but I guess it's
worth a shot.

>  Or, more generally, we may be able tell that a line matching with
> "^/bin/sh " is not an error message.

This would be wrong if you are compiling the file /bin/sh (unlikely as
that may seem).

Re: subtle problem of font-lock in *compilation* buffer

[Chong Yidong]

>> I don't know whqether it's uncommon or not, but if a packages uses
>> libtool with "-version-info M:N:L" argument, the above line
>> appears.  It may be too ad hoc but we can tell font-lock
>> that a line matching with the regexp "-version-info [0-9]"
>> is not an error message (if font-lock accepts such a
>> request).
>
> I don't see a straightforward way of doing this, but I guess it's
> worth a shot.

On further consideration, it's impossible to handle this perfectly:
consider compiling a file named "foo -version-info 1", which gives
rise to the error message

foo -version-info 1:0: blah blah
^^^^^^^^^^^^^^^^^^^

Re: subtle problem of font-lock in *compilation* buffer

[Kenichi Handa]

In article <87vensh1ol.fsf@furball.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:

> On further consideration, it's impossible to handle this perfectly:

Of course!  A simple way to cheat font-lock is to use "@echo
..." in Makefile.  

> consider compiling a file named "foo -version-info 1", which gives
> rise to the error message

> foo -version-info 1:0: blah blah
> ^^^^^^^^^^^^^^^^^^^

The question is which is important, to handle the above
extremely rare case correctly (and fail in more general
case), or to handle the more general case correctly (and
fail in rarer case).

---
Kenichi Handa
handa@m17n.org

Re: subtle problem of font-lock in *compilation* buffer

[Richard Stallman]

    On further consideration, it's impossible to handle this perfectly:
    consider compiling a file named "foo -version-info 1", which gives
    rise to the error message

    foo -version-info 1:0: blah blah
    ^^^^^^^^^^^^^^^^^^^

In the absence of a robust quoting convention for file names in error
messages, there will always be the possibility of confusion for
certain file names that contain unusual file names.

Our priority is to parse the messages correctly in the case of
sensible file names.  If this means that some bizarre file names will
cause trouble, too bad -- we recommend that people rename those files.

Would you like to fix Compilation mode to highlight these messages
properly in the normal case?

Re: subtle problem of font-lock in *compilation* buffer

[Richard Stallman]

    > How about by the spaces in the "file name"?

    It would wrongly reject compilation messages for file names containing
    spaces.

I'd rather have that problem than the problem we have now.
People shouldn't use such names for their source files.

    >  Or, more generally, we may be able tell that a line matching with
    > "^/bin/sh " is not an error message.

    This would be wrong if you are compiling the file /bin/sh (unlikely as
    that may seem).

I'd rather have that problem than the problem we have now.  For
/bin/sh to be a source file is not just absurd, but impossible as well
on GNU-like systems.

Re: subtle problem of font-lock in *compilation* buffer

[Stefan Monnier]

>> How about by the spaces in the "file name"?
>     It would wrongly reject compilation messages for file names containing
>     spaces.

> I'd rather have that problem than the problem we have now.
> People shouldn't use such names for their source files.

Sadly, it seems to be becoming more and more common for people to use spaces
in their file/directory names.

OTOH it's still rather unusual to have " -" in a file name, so maybe we can
use that as a telltale sign that we're not looking at a file name (and
hence not an error message either)?


        Stefan

Re: subtle problem of font-lock in *compilation* buffer

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> OTOH it's still rather unusual to have " -" in a file name, so maybe
> we can use that as a telltale sign that we're not looking at a file
> name (and hence not an error message either)?

Good idea.  This seems to work, as far as I can tell.

*** emacs/lisp/progmodes/compile.el.~1.407.~	2006-09-12 12:50:21.000000000 -0400
--- emacs/lisp/progmodes/compile.el	2006-09-13 16:15:56.000000000 -0400
***************
*** 229,235 ****
       ;; the last line tries to rule out message where the info after the
       ;; line number starts with "SS".  --Stef
       "^\\(?:[[:alpha:]][-[:alnum:].]+: ?\\)?\
! \\([0-9]*[^0-9\n].*?\\): ?\
  \\([0-9]+\\)\\(?:\\([.:]\\)\\([0-9]+\\)\\)?\
  \\(?:-\\([0-9]+\\)?\\(?:\\3\\([0-9]+\\)\\)?\\)?:\
  \\(?: *\\(\\(?:Future\\|Runtime\\)?[Ww]arning\\|W:\\)\\|\
--- 229,235 ----
       ;; the last line tries to rule out message where the info after the
       ;; line number starts with "SS".  --Stef
       "^\\(?:[[:alpha:]][-[:alnum:].]+: ?\\)?\
! \\([0-9]*[^0-9\n]\\(?:[^\n ]\\| [^-\n]\\)*?\\): ?\
  \\([0-9]+\\)\\(?:\\([.:]\\)\\([0-9]+\\)\\)?\
  \\(?:-\\([0-9]+\\)?\\(?:\\3\\([0-9]+\\)\\)?\\)?:\
  \\(?: *\\(\\(?:Future\\|Runtime\\)?[Ww]arning\\|W:\\)\\|\

Re: subtle problem of font-lock in *compilation* buffer

[Richard Stallman]

    Sadly, it seems to be becoming more and more common for people to use spaces
    in their file/directory names.

We can try to find clever ways to distinguish, as you've done here.
(Thanks for thinking of it.)

Despite the best we can do, there will still be some names that could
be confused with parts of compiler messages, such that we can't
distinguish.  When that happens, we have to parse the compiler
messages properly.  If someone actually uses a name that causes
confusion, we have to tell him "Don't use names like that."

Re: subtle problem of font-lock in *compilation* buffer

[Stefan Monnier]

>     Sadly, it seems to be becoming more and more common for people to use
>     spaces in their file/directory names.

> We can try to find clever ways to distinguish, as you've done here.
> (Thanks for thinking of it.)

> Despite the best we can do, there will still be some names that could
> be confused with parts of compiler messages, such that we can't
> distinguish.  When that happens, we have to parse the compiler
> messages properly.  If someone actually uses a name that causes
> confusion, we have to tell him "Don't use names like that."

One problem is that he may not have a choice.  His home directory may
already contain spaces in its name (quite common under w32).


        Stefan

Re: subtle problem of font-lock in *compilation* buffer

[Richard Stallman]

    One problem is that he may not have a choice.  His home directory may
    already contain spaces in its name (quite common under w32).

His home directory won't normally appear in the error messages.
They normally use relative file names.

Re: subtle problem of font-lock in *compilation* buffer

[Juri Linkov]

>     Sadly, it seems to be becoming more and more common for people to use spaces
>     in their file/directory names.
>
> We can try to find clever ways to distinguish, as you've done here.
> (Thanks for thinking of it.)
>
> Despite the best we can do, there will still be some names that could
> be confused with parts of compiler messages, such that we can't
> distinguish.  When that happens, we have to parse the compiler
> messages properly.  If someone actually uses a name that causes
> confusion, we have to tell him "Don't use names like that."

The next version of GNU grep will output special markers around
file names in the grep output.  We could use them after the release.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: subtle problem of font-lock in *compilation* buffer

[Richard Stallman]

    The next version of GNU grep will output special markers around
    file names in the grep output.

That would work for grep, if it is GNU grep; but it won't work
for compilation.