all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* subtle problem of font-lock in *compilation* buffer
@ 2006-09-06  8:16 Kenichi Handa
  2006-09-11  2:59 ` Chong Yidong
  0 siblings, 1 reply; 16+ messages in thread
From: Kenichi Handa @ 2006-09-06  8:16 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-06  8:16 subtle problem of font-lock in *compilation* buffer Kenichi Handa
@ 2006-09-11  2:59 ` Chong Yidong
  2006-09-11  3:56   ` Kenichi Handa
  2006-09-11 19:57   ` Richard Stallman
  0 siblings, 2 replies; 16+ messages in thread
From: Chong Yidong @ 2006-09-11  2:59 UTC (permalink / raw)
  Cc: emacs-devel

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).

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-11  2:59 ` Chong Yidong
@ 2006-09-11  3:56   ` Kenichi Handa
  2006-09-11 19:57   ` Richard Stallman
  1 sibling, 0 replies; 16+ messages in thread
From: Kenichi Handa @ 2006-09-11  3:56 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-11  2:59 ` Chong Yidong
  2006-09-11  3:56   ` Kenichi Handa
@ 2006-09-11 19:57   ` Richard Stallman
  2006-09-12 22:50     ` Chong Yidong
  1 sibling, 1 reply; 16+ messages in thread
From: Richard Stallman @ 2006-09-11 19:57 UTC (permalink / raw)
  Cc: emacs-devel, handa

    > /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"?

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-11 19:57   ` Richard Stallman
@ 2006-09-12 22:50     ` Chong Yidong
  2006-09-13  3:42       ` Chong Yidong
  2006-09-13 19:24       ` Richard Stallman
  0 siblings, 2 replies; 16+ messages in thread
From: Chong Yidong @ 2006-09-12 22:50 UTC (permalink / raw)
  Cc: emacs-devel, handa

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).

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-12 22:50     ` Chong Yidong
@ 2006-09-13  3:42       ` Chong Yidong
  2006-09-13  4:07         ` Kenichi Handa
  2006-09-13 19:24         ` Richard Stallman
  2006-09-13 19:24       ` Richard Stallman
  1 sibling, 2 replies; 16+ messages in thread
From: Chong Yidong @ 2006-09-13  3:42 UTC (permalink / raw)
  Cc: handa, emacs-devel

>> 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
^^^^^^^^^^^^^^^^^^^

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-13  3:42       ` Chong Yidong
@ 2006-09-13  4:07         ` Kenichi Handa
  2006-09-13 19:24         ` Richard Stallman
  1 sibling, 0 replies; 16+ messages in thread
From: Kenichi Handa @ 2006-09-13  4:07 UTC (permalink / raw)
  Cc: rms, emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-12 22:50     ` Chong Yidong
  2006-09-13  3:42       ` Chong Yidong
@ 2006-09-13 19:24       ` Richard Stallman
  2006-09-13 19:45         ` Stefan Monnier
  1 sibling, 1 reply; 16+ messages in thread
From: Richard Stallman @ 2006-09-13 19:24 UTC (permalink / raw)
  Cc: emacs-devel, handa

    > 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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-13  3:42       ` Chong Yidong
  2006-09-13  4:07         ` Kenichi Handa
@ 2006-09-13 19:24         ` Richard Stallman
  1 sibling, 0 replies; 16+ messages in thread
From: Richard Stallman @ 2006-09-13 19:24 UTC (permalink / raw)
  Cc: emacs-devel, handa

    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?

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-13 19:24       ` Richard Stallman
@ 2006-09-13 19:45         ` Stefan Monnier
  2006-09-13 20:17           ` Chong Yidong
  2006-09-15 14:29           ` Richard Stallman
  0 siblings, 2 replies; 16+ messages in thread
From: Stefan Monnier @ 2006-09-13 19:45 UTC (permalink / raw)
  Cc: Chong Yidong, handa, emacs-devel

>> 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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-13 19:45         ` Stefan Monnier
@ 2006-09-13 20:17           ` Chong Yidong
  2006-09-15 14:29           ` Richard Stallman
  1 sibling, 0 replies; 16+ messages in thread
From: Chong Yidong @ 2006-09-13 20:17 UTC (permalink / raw)
  Cc: handa, rms, emacs-devel

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:\\)\\|\

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-13 19:45         ` Stefan Monnier
  2006-09-13 20:17           ` Chong Yidong
@ 2006-09-15 14:29           ` Richard Stallman
  2006-09-15 16:27             ` Stefan Monnier
  2006-09-17 19:17             ` Juri Linkov
  1 sibling, 2 replies; 16+ messages in thread
From: Richard Stallman @ 2006-09-15 14:29 UTC (permalink / raw)
  Cc: cyd, handa, emacs-devel

    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."

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-15 14:29           ` Richard Stallman
@ 2006-09-15 16:27             ` Stefan Monnier
  2006-09-16 19:04               ` Richard Stallman
  2006-09-17 19:17             ` Juri Linkov
  1 sibling, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2006-09-15 16:27 UTC (permalink / raw)
  Cc: cyd, handa, emacs-devel

>     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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-15 16:27             ` Stefan Monnier
@ 2006-09-16 19:04               ` Richard Stallman
  0 siblings, 0 replies; 16+ messages in thread
From: Richard Stallman @ 2006-09-16 19:04 UTC (permalink / raw)
  Cc: cyd, emacs-devel, handa

    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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-15 14:29           ` Richard Stallman
  2006-09-15 16:27             ` Stefan Monnier
@ 2006-09-17 19:17             ` Juri Linkov
  2006-09-18 18:50               ` Richard Stallman
  1 sibling, 1 reply; 16+ messages in thread
From: Juri Linkov @ 2006-09-17 19:17 UTC (permalink / raw)
  Cc: cyd, emacs-devel, monnier, handa

>     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/

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: subtle problem of font-lock in *compilation* buffer
  2006-09-17 19:17             ` Juri Linkov
@ 2006-09-18 18:50               ` Richard Stallman
  0 siblings, 0 replies; 16+ messages in thread
From: Richard Stallman @ 2006-09-18 18:50 UTC (permalink / raw)
  Cc: cyd, emacs-devel, monnier, handa

    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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2006-09-18 18:50 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-06  8:16 subtle problem of font-lock in *compilation* buffer Kenichi Handa
2006-09-11  2:59 ` Chong Yidong
2006-09-11  3:56   ` Kenichi Handa
2006-09-11 19:57   ` Richard Stallman
2006-09-12 22:50     ` Chong Yidong
2006-09-13  3:42       ` Chong Yidong
2006-09-13  4:07         ` Kenichi Handa
2006-09-13 19:24         ` Richard Stallman
2006-09-13 19:24       ` Richard Stallman
2006-09-13 19:45         ` Stefan Monnier
2006-09-13 20:17           ` Chong Yidong
2006-09-15 14:29           ` Richard Stallman
2006-09-15 16:27             ` Stefan Monnier
2006-09-16 19:04               ` Richard Stallman
2006-09-17 19:17             ` Juri Linkov
2006-09-18 18:50               ` Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.