emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel Pfeiffer
Subject: Re: new compile command doesn't coalesce errors on the same line
Date: Sun, 21 Mar 2004 09:22:24 +0100

Saluton, Moin,

Richard Stallman <address@hidden> 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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]