new compile command doesn't coalesce errors on the same line

new compile command doesn't coalesce errors on the same line

[Miles Bader]

If *compilation* looks like this:

cray.c:33: error: `driver_num' undeclared (first use in this function)
cray.c:33: error: (Each undeclared identifier is reported only once
cray.c:33: error: for each function it appears in.)
cray.c:36: error: too many arguments to function `make_driver'

Then the first next-error jumps to (having working around the problems
with next-error described in my previous mail) line 33.

However, the next 2 invocations of `M-x next-error' _also_ jump to line
33, which is obvious a bit of a pain (since multi-line error messages
like that are common from gcc).  The old compile command simply ignored
any error lines which were duplicates.

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: new compile command doesn't coalesce errors on the same line

[Daniel Pfeiffer]

Saluton,

Miles Bader <miles@lsi.nec.co.jp> skribis:

> If *compilation* looks like this:
> 
> cray.c:33: error: `driver_num' undeclared (first use in this function)
> cray.c:33: error: (Each undeclared identifier is reported only once
> cray.c:33: error: for each function it appears in.)
> cray.c:36: error: too many arguments to function `make_driver'
> 
> Then the first next-error jumps to (having working around the problems
> with next-error described in my previous mail) line 33.
> 
> However, the next 2 invocations of `M-x next-error' _also_ jump to line
> 33, which is obvious a bit of a pain (since multi-line error messages
> like that are common from gcc).  The old compile command simply ignored
> any error lines which were duplicates.

compilation-skip-visited is your friend.  I chose not to default this to true,
because these may be several errors, and somebody might oversee that there was
more.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

P.S.: gnu.org is bouncing my mails.  If this doesn't show up on the list,
could you please forward it?

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: new compile command doesn't coalesce errors on the same line

[Daniel Pfeiffer]

Saluton, Moin,

Miles Bader <miles@lsi.nec.co.jp> skribis:

> If *compilation* looks like this:
> 
> cray.c:33: error: `driver_num' undeclared (first use in this function)
> cray.c:33: error: (Each undeclared identifier is reported only once
> cray.c:33: error: for each function it appears in.)

And I would say that is a bug in gcc, because the other 2 lines are
mislabeled.  They are _not_ errors, but merely informational.  If this were:

cray.c:33: error: `driver_num' undeclared (first use in this function)
cray.c:33: info: (Each undeclared identifier is reported only once
cray.c:33: information: for each function it appears in.)

compilation-mode would do the right thing.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: new compile command doesn't coalesce errors on the same line

[Miles Bader]

On Wed, Mar 17, 2004 at 09:58:11PM +0100, Daniel Pfeiffer wrote:
> And I would say that is a bug in gcc, because the other 2 lines are
> mislabeled.  They are _not_ errors, but merely informational.  If this were:

This is the context within which compile has to work.

-Miles
-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: new compile command doesn't coalesce errors on the same line

[Miles Bader]

On Wed, Mar 17, 2004 at 09:52:08PM +0100, Daniel Pfeiffer wrote:
> compilation-skip-visited is your friend.  I chose not to default this to
> true, because these may be several errors, and somebody might oversee that
> there was more.

No, it must default to t.

There are certainly occasions when skipping identical errors with the same
line is awkward, but the old compile did so for a good reason -- with current
compilers etc., usually it's the right thing to do.

[No, you don't have the option of changing the compilers! :-]

-Miles
-- 
Fast, small, soon; pick any 2.

Re: new compile command doesn't coalesce errors on the same line

[Stefan Monnier]

>> compilation-skip-visited is your friend.  I chose not to default this to
>> true, because these may be several errors, and somebody might oversee that
>> there was more.
> No, it must default to t.

Actually the option has existed for a long time and has always been nil.
So maybe we're talking about something else here,


        Stefan

Re: new compile command doesn't coalesce errors on the same line

[Kim F. Storm]

dapfy@t-online.de (Daniel Pfeiffer) writes:

> Saluton,
> 
> Miles Bader <miles@lsi.nec.co.jp> skribis:
> 
> > If *compilation* looks like this:
> > 
> > cray.c:33: error: `driver_num' undeclared (first use in this function)
> > cray.c:33: error: (Each undeclared identifier is reported only once
> > cray.c:33: error: for each function it appears in.)
> > cray.c:36: error: too many arguments to function `make_driver'
> > 
> > Then the first next-error jumps to (having working around the problems
> > with next-error described in my previous mail) line 33.
> > 
> > However, the next 2 invocations of `M-x next-error' _also_ jump to line
> > 33, which is obvious a bit of a pain (since multi-line error messages
> > like that are common from gcc).  The old compile command simply ignored
> > any error lines which were duplicates.
> 
> compilation-skip-visited is your friend.  I chose not to default this to true,
> because these may be several errors, and somebody might oversee that there was
> more.

One error in a line often leads to multiple error messages; I think there
should be an option to skip multiple references to the same line.  

IMO, default for compilation-skip-visited should be t.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: new compile command doesn't coalesce errors on the same line

[Andreas Schwab]

dapfy@t-online.de (Daniel Pfeiffer) writes:

> Saluton, Moin,
>
> Miles Bader <miles@lsi.nec.co.jp> skribis:
>
>> If *compilation* looks like this:
>> 
>> cray.c:33: error: `driver_num' undeclared (first use in this function)
>> cray.c:33: error: (Each undeclared identifier is reported only once
>> cray.c:33: error: for each function it appears in.)
>
> And I would say that is a bug in gcc, because the other 2 lines are
> mislabeled.  They are _not_ errors, but merely informational.  If this were:

It's a multiline error message, _not_ three different ones.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: new compile command doesn't coalesce errors on the same line

[Daniel Pfeiffer]

Hi Stefan,

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

> >> compilation-skip-visited is your friend.  I chose not to default this to
> >> true, because these may be several errors, and somebody might oversee
> >that> there was more.
> > No, it must default to t.
> 
> Actually the option has existed for a long time and has always been nil.
> So maybe we're talking about something else here,

This option was not present in Revision: 1.256.2.6, i.e. before my version got
in.  Remember you've been using my version for months but it's only recently
become standard.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: new compile command doesn't coalesce errors on the same line

[Daniel Pfeiffer]

Moin Andreas,

Andreas Schwab <schwab@suse.de> skribis:

> dapfy@t-online.de (Daniel Pfeiffer) writes:
> 
> > Saluton, Moin,
> >
> > Miles Bader <miles@lsi.nec.co.jp> skribis:
> >
> >> If *compilation* looks like this:
> >> 
> >> cray.c:33: error: `driver_num' undeclared (first use in this function)
> >> cray.c:33: error: (Each undeclared identifier is reported only once
> >> cray.c:33: error: for each function it appears in.)
> >
> > And I would say that is a bug in gcc, because the other 2 lines are
> > mislabeled.  They are _not_ errors, but merely informational.  If this
> > were:
> 
> It's a multiline error message, _not_ three different ones.

It is three different messages, even if the stupid compiler writer intended
something different.  But the general feeling here seems to be to make this
default to t.  Those who have clever compilers that report columns will still
get the benefit of jumping to each different column.

I have no objection to making this t.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: new compile command doesn't coalesce errors on the same line

[Richard Stallman]

    >> compilation-skip-visited is your friend.

    Actually the option has existed for a long time and has always been nil.
    So maybe we're talking about something else here,

The doc string is very hard to understand--it is written like a
program.  It may be 100% precise, but it is not very useful.  Can
someone who understands that option's meaning rewrite the doc stringq
to be readable?

Meanwhile, to the extent I can figure it out, I think this is indeed
something else.  Let's just change the code so as to treat
contiguous errors as one.

Re: new compile command doesn't coalesce errors on the same line

[Daniel Pfeiffer]

Saluton, Moin,

Richard Stallman <rms@gnu.org> skribis:

>     >> compilation-skip-visited is your friend.
> 
>     Actually the option has existed for a long time and has always been nil.
>     So maybe we're talking about something else here,
> 
> The doc string is very hard to understand--it is written like a
> program.  It may be 100% precise, but it is not very useful.  Can
> someone who understands that option's meaning rewrite the doc stringq
> to be readable?

Are we talking about the same docstring?  I (having written it :-) find it
quite clear:

  "*Compilation motion commands skip visited messages if this is t.
Visited messages are ones for which the file, line and column have been jumped
to from the current content in the current compilation buffer, even if it was
from a different message."

"current" here refers to the same compilation.  When I compile again,
everything starts over.

> Meanwhile, to the extent I can figure it out, I think this is indeed
> something else.  Let's just change the code so as to treat
> contiguous errors as one.

How contiguous do they have to be?  How many lines apart may they be?  Keep
this in mind:  Where the old compile was bound to line-beginnings, the new one
can match a location anywhere on a line, even several different kinds on the
same line as in

foo.c:5: error: function f was declared differently at bar.h:17
foo.c:5: error: (this is some bla bla about the same spot)

To the human reader, the two foo.c:5 are still contiguous.   But to the
program bar.h:17 came in between.  It could get quite complicated.

What would we gain?  Why would I want to go to the same spot again if it is
mentioned 3 lines down, but not when it is mentioned on the next line?

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: new compile command doesn't coalesce errors on the same line

[Miles Bader]

On Sat, Mar 20, 2004 at 07:41:37AM +0100, Daniel Pfeiffer wrote:
> > Meanwhile, to the extent I can figure it out, I think this is indeed
> > something else.  Let's just change the code so as to treat
> > contiguous errors as one.
> 
> How contiguous do they have to be?  How many lines apart may they be?  Keep
> this in mind: Where the old compile was bound to line-beginnings, the new
> one can match a location anywhere on a line, even several different kinds
> on the same line as in
>
> What would we gain?  Why would I want to go to the same spot again if it is
> mentioned 3 lines down, but not when it is mentioned on the next line?

It has to _at least_ handle correctly the cases the old compile command did.

Geez, I'm beginning to think it would be easier just to put the old one back.

-Miles
-- 
`Life is a boundless sea of bitterness'

Re: new compile command doesn't coalesce errors on the same line

[Daniel Pfeiffer]

Hi Miles,

I'm not sure a compiler with buggy messages should force the default value for
compilation-skip-visited.  But gcc is probably the most frequently used
program inside compile, so I'd already accepted what looks like the majority
verdict, of making this option be t.  For those who would like to set it to
nil, here's an example of four messages pertaining to one line, and only two
are directly related:

$ perl -we '$x = foo; print "$y\n"'
Unquoted string "foo" may clash with future reserved word at -e line 1.
Name "main::y" used only once: possible typo at -e line 1.
Name "main::x" used only once: possible typo at -e line 1.
Use of uninitialized value in concatenation (.) or string at -e line 1.

Miles Bader <miles@gnu.org> skribis:

> On Sat, Mar 20, 2004 at 07:41:37AM +0100, Daniel Pfeiffer wrote:
> > > Meanwhile, to the extent I can figure it out, I think this is indeed
> > > something else.  Let's just change the code so as to treat
> > > contiguous errors as one.
> > 
> > How contiguous do they have to be?  How many lines apart may they be? 
> > Keep this in mind: Where the old compile was bound to line-beginnings, the
> > new one can match a location anywhere on a line, even several different
> > kinds on the same line as in
> >
> > What would we gain?  Why would I want to go to the same spot again if it
> > is mentioned 3 lines down, but not when it is mentioned on the next line?
> 
> It has to _at least_ handle correctly the cases the old compile command did.

And those are?  I asked some clear questions.  What is it you want that my
option can not give you?  And how do you want to handle the example I gave
(recognizing multiple locations on a line), which you didn't answer?

> Geez, I'm beginning to think it would be easier just to put the old one
> back.

Geez, you've got your very constructive day again!  The old one was awful, not
differentiating an error from a warning or info, clueless about multiple
locations on a line, randomly pretending there's no error on the current line
even though it's highlighted or sometimes even going to a wrong file...

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: new compile command doesn't coalesce errors on the same line

[Richard Stallman]

    Are we talking about the same docstring?  I (having written it :-) find it
    quite clear:

      "*Compilation motion commands skip visited messages if this is t.
    Visited messages are ones for which the file, line and column have been jumped
    to from the current content in the current compilation buffer, even if it was
    from a different message."

Yes, that is the docstring I can't understand.

Re: new compile command doesn't coalesce errors on the same line

[Richard Stallman]

    > Meanwhile, to the extent I can figure it out, I think this is indeed
    > something else.  Let's just change the code so as to treat
    > contiguous errors as one.

    How contiguous do they have to be?

I'd suggest that if one error and the next error point to the same
location then they are contiguous.

    What would we gain?  Why would I want to go to the same spot again if it is
    mentioned 3 lines down, but not when it is mentioned on the next line?

The point is to do the convenient thing in a simple common case of
multiple errors from a single line.  What happens in the strange cases
is less important because they are rare.  So you may as well handle
them in whatever way seems most correct.

Re: new compile command doesn't coalesce errors on the same line

[Daniel Pfeiffer]

Saluton, Moin,

Richard Stallman <rms@gnu.org> skribis:
>     Are we talking about the same docstring?  I (having written it :-) find
>     it quite clear:
> 
>       "*Compilation motion commands skip visited messages if this is t.
>     Visited messages are ones for which the file, line and column have been
>     jumped to from the current content in the current compilation buffer,
>     even if it was from a different message."
> 
> Yes, that is the docstring I can't understand.

Is this better?

*Compilation motion commands skip visited locations if this is t.
A location is considered visited if you've already jumped there.  It doesn't
matter if this happened from a different message.  After you start a new
compilation, all locations will again be initially considered unvisited.

>     > Meanwhile, to the extent I can figure it out, I think this is indeed
>     > something else.  Let's just change the code so as to treat
>     > contiguous errors as one.
> 
>     How contiguous do they have to be?
> 
> I'd suggest that if one error and the next error point to the same
> location then they are contiguous.

The example I cited

location a: ... location b
location a: more bla about a

is not contrived.  I've seen this frequently at work.  The old compile simply
ignored location b.  Now it is found and breaks immediate contiguousness.

>     What would we gain?  Why would I want to go to the same spot again if it
>     is mentioned 3 lines down, but not when it is mentioned on the next
>     line?
> 
> The point is to do the convenient thing in a simple common case of
> multiple errors from a single line.  What happens in the strange cases
> is less important because they are rare.  So you may as well handle
> them in whatever way seems most correct.

Well, the most convenient (also for messages in headers, which get rereported
1000 times) would be to set compilation-skip-visited to t, like a few people
requested.  This would automatically cover the case of contiguous messages,
without the hassle of searching for same locations in the vicinity.  Does my
suggested new documentation make this more appealing?

But if we get a few votes for a necessity to skip-same-near-messages "yes",
skip-same-far-messages "no" it wouldn't be impossible to implement.  In that
case the documentation would become:

*Compilation motion commands skip visited locations if this is non-nil.
A location is considered visited if you've already jumped there.  It doesn't
matter if this happened from a different message.

If this is t, you will not go to the same location again.  If this is a
number, that only applies if the visited location is mentioned in that many
preceding (following when moving backwards) lines.

After you start a new compilation, all locations will again be initially
considered unvisited.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: new compile command doesn't coalesce errors on the same line

[Richard Stallman]

    Unquoted string "foo" may clash with future reserved word at -e line 1.
    Name "main::y" used only once: possible typo at -e line 1.
    Name "main::x" used only once: possible typo at -e line 1.
    Use of uninitialized value in concatenation (.) or string at -e line 1.

It is not unusual to have unrelated errors on the same line.
That happens in C as well.

However, once next-error shows the user the line, he will see
all the error messages about it, and will probably fix them all.
If the next use of next-error goes to the second error on that line,
the user just finds it a nuisance.  He has to type next-error
several times just to get to an error he hasn't deal with already.

So we want next-error to go to the next error for a different place.

Re: new compile command doesn't coalesce errors on the same line

[Richard Stallman]

    *Compilation motion commands skip visited locations if this is t.
    A location is considered visited if you've already jumped there.  It doesn't
    matter if this happened from a different message.  After you start a new
    compilation, all locations will again be initially considered unvisited.

The condition is clear now.  I am not sure what "Compilation motion
commands" are or what "skip" means.  Could you explain?

What will happen if I move up in the compilation buffer and type RET
to revisit an error I already saw?  Will it be "skipped"?

What if I then type C-x `?  Will it got to the following error,
or will it move down until it finds an error I have not yet visited?

    The example I cited

    location a: ... location b
    location a: more bla about a

    is not contrived.  I've seen this frequently at work.  The old compile simply
    ignored location b.  Now it is found and breaks immediate contiguousness.

I see what you mean.  I don't have an opinion about it.
I won't say this is a bad change.

Re: new compile command doesn't coalesce errors on the same line

[Daniel Pfeiffer]

Saluton, Moin,

Richard Stallman <rms@gnu.org> skribis:

>     *Compilation motion commands skip visited locations if this is t.
>     A location is considered visited if you've already jumped there.  It
>     doesn't matter if this happened from a different message.  After you
>     start a new compilation, all locations will again be initially
>     considered unvisited.
> 
> The condition is clear now.  I am not sure what "Compilation motion
> commands" are or what "skip" means.  Could you explain?

I believe I've inherited the term "Compilation motion commands" from the old
library.  They are the various next- or previous-error type of commands.

> What will happen if I move up in the compilation buffer and type RET
> to revisit an error I already saw?  Will it be "skipped"?

RET or mouse clicking is not motion in the above sense.  It tells Emacs "I
want to go to _this_ location" and that is of course always honoured.

> What if I then type C-x `?  Will it got to the following error,
> or will it move down until it finds an error I have not yet visited?

That is exactly the distinction made by the compilation-skip-visited option. 
You can have one behaviour or the other.

>     The example I cited
> 
>     location a: ... location b
>     location a: more bla about a
> 
>     is not contrived.  I've seen this frequently at work.  The old compile
>     simply ignored location b.  Now it is found and breaks immediate
>     contiguousness.
> 
> I see what you mean.  I don't have an opinion about it.
> I won't say this is a bad change.

This is only important if people want to be able to distinguish skipping
nearby mentions of the same location, but not far away ones.  I had called for
a vote on this a few days ago, and so far noone has come forward to say they
must have this distinction.

Then I'd say we stick with compilation-skip-visited's current behaviour.  We'd
just make it default to t as several people requested.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: new compile command doesn't coalesce errors on the same line

[Richard Stallman]

    > What if I then type C-x `?  Will it got to the following error,
    > or will it move down until it finds an error I have not yet visited?

    That is exactly the distinction made by the compilation-skip-visited option. 
    You can have one behaviour or the other.

Now I understand.  The doc string was not clear to me.

I am now certain that setting compilation-skip-visited to t is NOT the
right way to handle consecutive errors on one source line.  It has
other effects that I would not want.

So compilation-skip-visited's default should remain nil,
but we need another feature to recognize consecutive error messages
on a single source line and disregard all but the first of them.

Would you please implement that feature?  There could be an
option to disable it.

Re: new compile command doesn't coalesce errors on the same line

[Daniel Pfeiffer]

Saluton, Moin,

Richard Stallman <rms@gnu.org> skribis:

>     > What if I then type C-x `?  Will it got to the following error,
>     > or will it move down until it finds an error I have not yet visited?
> 
>     That is exactly the distinction made by the compilation-skip-visited
>     option. You can have one behaviour or the other.
> 
> Now I understand.  The doc string was not clear to me.
> 
> I am now certain that setting compilation-skip-visited to t is NOT the
> right way to handle consecutive errors on one source line.  It has
> other effects that I would not want.
> 
> So compilation-skip-visited's default should remain nil,
> but we need another feature to recognize consecutive error messages
> on a single source line and disregard all but the first of them.
> 
> Would you please implement that feature?  There could be an
> option to disable it.

Sure, but I'm still not clear on what contiguous should mean.  What if there
are ten contiguous mentions of a location, but the *compilation* window is
only five lines high?  I'd still be skipping five unseen messages.  What if
the window is not visible?  Remember how much of it was displayed when last
going to an error?

How about intervening lines, as a compiler at work gives me?  Are these still
contiguous:

a.c:9: bla bla
	bla bla happened here:
	y = f( x );
                 ^
a.c:9: foo bar ...

I guess we'd need to limit the height of a contiguous block to the (most
recently) visible lines, and ignore anything else there is within that area.
And we'd need the remember the recently visited locations.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/

Re: new compile command doesn't coalesce errors on the same line

[Stefan Monnier]

> Sure, but I'm still not clear on what contiguous should mean.  What if there
> are ten contiguous mentions of a location, but the *compilation* window is
> only five lines high?  I'd still be skipping five unseen messages.  What if
> the window is not visible?  Remember how much of it was displayed when last
> going to an error?

Writing elisp code that depends on visibility is asking for trouble:
What if it's not visible in the current window, but is visible in some other
window?  And what if it's visible in the current window but that window is
hidden by another frame, or iconified, or outside of the current viewport?
So just disregard those corner cases, please.

> How about intervening lines, as a compiler at work gives me?  Are these still
> contiguous:

> a.c:9: bla bla
> 	bla bla happened here:
> 	y = f( x );
>                  ^
> a.c:9: foo bar ...

The old code was happy to just look at the previous error (not "the error on
the previous line" or anything like that), IIRC, so that should be good
enough here as well.


        Stefan

Re: new compile command doesn't coalesce errors on the same line

[David Kastrup]

dapfy@t-online.de (Daniel Pfeiffer) writes:

> Richard Stallman <rms@gnu.org> skribis:
> 
> >     > What if I then type C-x `?  Will it got to the following error,
> >     > or will it move down until it finds an error I have not yet visited?
> > 
> >     That is exactly the distinction made by the compilation-skip-visited
> >     option. You can have one behaviour or the other.
> > 
> > Now I understand.  The doc string was not clear to me.
> > 
> > I am now certain that setting compilation-skip-visited to t is NOT the
> > right way to handle consecutive errors on one source line.  It has
> > other effects that I would not want.
> > 
> > So compilation-skip-visited's default should remain nil,
> > but we need another feature to recognize consecutive error messages
> > on a single source line and disregard all but the first of them.
> > 
> > Would you please implement that feature?  There could be an
> > option to disable it.
> 
> Sure, but I'm still not clear on what contiguous should mean.  What if there
> are ten contiguous mentions of a location, but the *compilation* window is
> only five lines high?

Make it larger temporarily.  That's what happens to the minibuffer in
similar cases.  Of course I have no idea how to achieve that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: new compile command doesn't coalesce errors on the same line

[Kim F. Storm]

dapfy@t-online.de (Daniel Pfeiffer) writes:

> How about intervening lines, as a compiler at work gives me?  Are these still
> contiguous:
> 
> a.c:9: bla bla
> 	bla bla happened here:
> 	y = f( x );
>                  ^
> a.c:9: foo bar ...

IMHO, to keep things simple, I would say no.

> 
> I guess we'd need to limit the height of a contiguous block to the (most
> recently) visible lines, and ignore anything else there is within that area.

All of this sounds overly complicated.

Can't it simply be done by saying that if two or more consecutive
lines points to the same source line, it shall ignore all but the first one.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: new compile command doesn't coalesce errors on the same line

[Richard Stallman]

    Sure, but I'm still not clear on what contiguous should mean.  What if there
    are ten contiguous mentions of a location, but the *compilation* window is
    only five lines high?

The height of the window should not matter.  The old code would have
skipped them, and nobody ever complained about that.  Perhaps because
users don't often use such short windows.  Or if they do, and the
errors about one line reach the bottom, they scroll it.

    How about intervening lines, as a compiler at work gives me?  Are these still
    contiguous:

    a.c:9: bla bla
	    bla bla happened here:
	    y = f( x );
		     ^
    a.c:9: foo bar ...

If the old code treated them as contiguous, please preserve that behavior.
This is simple.

Re: new compile command doesn't coalesce errors on the same line

[Daniel Pfeiffer]

Hi all,

Richard Stallman <rms@gnu.org> skribis:

>     > What if I then type C-x `?  Will it got to the following error,
>     > or will it move down until it finds an error I have not yet visited?
> 
>     That is exactly the distinction made by the compilation-skip-visited
>     option. You can have one behaviour or the other.
> 
> Now I understand.  The doc string was not clear to me.
> 
> I am now certain that setting compilation-skip-visited to t is NOT the
> right way to handle consecutive errors on one source line.  It has
> other effects that I would not want.
> 
> So compilation-skip-visited's default should remain nil,
> but we need another feature to recognize consecutive error messages
> on a single source line and disregard all but the first of them.
> 
> Would you please implement that feature?  There could be an
> option to disable it.

I just noticed it is there already.  I inherited from the old mode
compilation-skip-to-next-location which was default nil.  So I retained that
value.  The snag is that the implementation of this was redundant, so the
value didn't matter.  So if I now default it to t, we get skipping of
contiguous messages :-)

I'll check that in these days.

coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer

-- 
lerne / learn / apprends / läramå / ucz się    Esperanto:
                              http://lernu.net/