Re: next-error refactoring

[Richard Stallman <rms@gnu.org>]

    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.

There is already an easy way to move between functions: C-M-a and
C-M-e.  However, I see no resemblance between that and next-error.

						 In dired, it could move
       to the next file.

I do see the resemblance between that and next-error.  However, it
would probably be simpler to define the same keys (more or less) with
parallel meanings but completely different code.

			  In W3 it could go back/forward in the history
       or between links.

I think that could perhaps be implemented using the existing
next-error mechanism, if that is useful.

    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.

To use a single set of key bindings, defined in just one place, would
be desirable.  I don't know whether it is possible.  Making each of
these modes have good key bindings is the first priority.  If it turns
out that a single set if bindings will work well for all of them, we
could easily write a subroutine to make those bindings in whatever
keymap.  That would achieve the simplification you are looking for.

The rest of the minor mode mechanism would be unnecessary, perhaps
even counterproductive.  We certainly do not want it to appear *to the
user* as a separate minor mode.  That would only be clutter, and suggest
to the user that he might want to consider turning the minor mode off,
which would always be a mistake.