Re: next-error refactoring

[Stefan Monnier]

> 1) There are many modes that can benefit from a next-error (or
>    whatever it's called by then) approach.  In code, for instance,
>    next-error could move between functions.  In dired, it could move
>    to the next file.  In W3 it could go back/forward in the history
>    or between links.

To me the concept of "next-error" refers to something that has the
following properties:
- every entry in the list of things to step through refers to a location
  in another buffer.
- you want to step through the locations referred to rather than only
  stepping through the entries themselves.
So I don´t see how it can usefully be applied to functions in a file.

I see that it can be handy to C-x ` through a list of files in dired in
some particular cases, tho.  But we then need to design some way to
distinguish between buffers where this is common and those where it is not,
otherwise people will be annoyed that C-x ` is always captured by their
dired buffer instead of compile, or things like that.  We´ve already seen
such problems with my adding C-x ` support to diff-mode.

> 2) Approaching next-error as we do now, in a haphazard fashion,
>    implemented specifically in every mode that needs to use it, is
>    painful for the developer.  It's much easier to provide hooks, a
>    keymap, and all the other niceties of a standalone minor mode.
>    Users will certainly appreciate that too.  Also, if and when
>    next-error changes, developers won't have to change their code.

I agree that more of the next-error code should be in the generic part of
the code (all the window-management comes to mind), but I also think this
is better done post-21.4.  Especially since we still don´t have any sample
code to try and we´re not sure what the new behavior should be.


        Stefan