[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FYI: more locations (PR/360) + question
From: |
Akim Demaille |
Subject: |
Re: FYI: more locations (PR/360) + question |
Date: |
30 Sep 2002 18:06:02 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter) |
| Index: automake.in
| ===================================================================
| RCS file: /cvs/automake/automake/automake.in,v
| retrieving revision 1.1371
| diff -u -r1.1371 automake.in
| --- automake.in 30 Sep 2002 12:32:20 -0000 1.1371
| +++ automake.in 30 Sep 2002 13:21:06 -0000
| @@ -291,7 +291,7 @@
|
| # We can't always associate a location to a variable or a rule,
| # when its defined by Automake. We use INTERNAL in this case.
| -use constant INTERNAL => new Automake::Location 'internal';
| +use constant INTERNAL => new Automake::Location;
|
:) :) I love your stuff :)
| >> Now I'm open to suggestions about how these diagnostics could be
| >> output in a way which is more readable. Would it be better to
| >> add a new line between each diagnostic, as follow?
|
| Akim> Well, let me speak as the devil :) Make the real error a read message
| Akim> when the TTY supports it :)
|
| What's a read message? "hit any key"?
Sorry, typo: s/read/red/.
| Akim> Maybe we should extend to GCS to support shifting the secondary
| Akim> locations to the right? Something like:
|
| Akim> /home/adl/projs/cvs/automake/HEAD2/tests/../lib/am/library.am: change
your target to read `libfoo.a$(EXEEXT)'
| Akim> Makefile.am:3: while processing library `libfoo.a'
|
| This could be nice. (So far I've been indenting only the text of
| secondary locations, but that obviously doesn't make it easier to read.)
That would be quite easy to have accepted from RMS provided you send a
patch for compile.el. Bundle this with a patch for the GCS.
| There are other questions related to diagnostic formating that could
| be answered by the GCS:
|
| - how should multiline diagnostics be displayed?
| Presently Automake repeats the location, as in
| foo:3: this message spans
| foo:3: over two lines
| (that was what Automake did before I introduced Automake::Channels so
| I simply copied that)
I'm afraid we ought to obey the tradition set with recent GCC (which
is what you display). But, BTW, I must say that I hate this tradition
for several reasons:
1. when I run the compilation under Emacs, I prefer infinite width
rather than arbitrary 80 col. But I agree this can be qualified as `a
matter of taste' (I don't agree though), the following is more
problematic...
2. because there can be message spread on several lines, Emacs makes
no difference with a line with *two* (or more) error messages, and
*skips* them when C-`. For instance, compile this:
int foo = 1++ + 1++;
int bar = 1++;
You'll see that next error goes to line 2, although:
foo.c:1: invalid lvalue in increment
foo.c:1: invalid lvalue in increment
foo.c:1: initializer element is not constant
foo.c:2: invalid lvalue in increment
I think the GCS should chose something that helps distinguishing the
two cases. Note that fine grained locations (with col and range) does
not eliminate the case of a single being responsible for *several*
errors.
| - how should errors and warnings be indicated? Presently the
| Automake user has no way to differentiate warnings from errors --
| well, except $?.
Ah! I missed that point! Undoubtedly there should be `warning: '.