Re: compilation-forget-errors still used by tex-mode.el

[storm@cua.dk (Kim F. Storm)]

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

> > - keep a marker to the next position (strange to not find the next error
> >   where the cursor is, though)
> 
> That's the old way.  It's actually not so strange in practice.
> And it allows the user to move around in the *compile* buffer without
> losing track of the "current error" (I'm not sure how important this is,
> but I suspect that some people rely on this on a regular basis).

Sometimes it would be nice if next error followed the cursor, other times not.
Problem is to say when you want one or the other behaviour.

There should be commands for both, e.g. C-x ` (next-error) takes next
error independently of point, while some other command (I'd prefer
RET, but that's another, old, discussion) takes you to the error on the
current line (or next error following it (and moves next-error marker
accordingly).

> 
> > - generally wrap around to the begining if any errors were skipped, and
> >   only signal this error if none are left (seems the most useful and
> >   consistent solution :-)
> 
> This indeed seems like an option, although I'm not sure whether people would
> find it helpful or annoying.  

So it should be an option.  It should be off in basic compilation
buffers, but for some modes, it might be quite useful.  

F.ex. in grep, where you could jump to specific occurrences first
(e.g. to fix a declaration or prototype), and then go through the rest
afterwards (to fix uses).


>                               If it's not too much coding, it might be
> worth trying it out.
> In that case the "beginning of errors" could be encoded by marking all
> previous errors as visited.
> 
> To be honest the idea of annotating every error with a `visited' flag
> doesn't sound too great.

As I said, it might be useful, but there should definitely be some
way to turn it off (or clear the visited flags).

> 
> My current patch basically reproduces the behavior of the old code:
> it re-introduces `compilation-parsing-end' and uses it as the "current
> error" marker.  While I think that using a marker is the best option and
> that re-introducing `compilation-parsing-end' for compatibility purposes is
> right as well, I'm not convinced that merging the two is such a hot idea.
> We should maybe just introduce a new `compilation-current-error' marker
> instead and keep `compilation-parsing-end' for compatibility only.

And add compilation-current-error to overlay-arrow-variable-list :-)

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