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

[Kenichi Handa <handa@m17n.org>]

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