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

[Stefan Monnier]

>> Indeed.  But that's also how it worked in Emacs-21.3.
>> I'm only trying to fix the *new* bugs for now.

> It worked in 20.7, using tex-start-tex-marker.  My own hack uses that
> as well and so I didn't notice that it was lost in 21.3.

Aaaaaahhhhhh!  Thanks!
Looking back at the changelog of tex-mode.el, I see that I'm the one who
botched this (due to my lack of knowledge of first-error).

So that brings us back to:

>>>>> "Daniel" == Daniel Pfeiffer <address@hidden> writes:
> Miles Bader <address@hidden> skribis:
>> When I do `M-x compile RET', type make, and get a bunch of errors, and
>> then try `M-x next-error', it doesn't work, and instead just says
>> `Moved past last error'.
>> 
>> If I go to the *compilation* buffer, and use `C-c C-c' on an error
>> line, then that succeeds, and subsequent uses of `next-error' also work
>> properly.

> Aha, that's a consequence of scrolling along with the output as it pours in,
> unless you move the cursor.  The (point) in the *compilation* buffer serves as
> the indication where the 'current' error is.  The next one will be found from
> there onwards.  Four possibilities:

So as Markus has reminded us, in Emacs-20.7 tex-mode correctly handled
`first-error' in that it brought compile.el back to the first error of the
last TeX run rather than the first error in the buffer.

So we need:
- point (of course).
- "current error" (the current code uses point for that, but the old code
  had a separate notion for this, represented by a mix of
  compilation-parsing-end and compilation-old-error-list).
- "beginning of errors" (to reset "current error" when we call
  `first-error').

> - not scroll along but stay at the beginning (not so nice)

Not an option for comint buffers.

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

> - remember (or check) that we haven't visited an error from this buffer,
>   and only in that case jump to the beginning

But we have to define what is meant by "have visited an error already" for
buffers where several commands might be executed.

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

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.


        Stefan