Re: next-error refactoring

[Ted Zlatanov]

On Wed, 02 Jun 2004, address@hidden wrote:

        >> Is it time to make next-error a minor mode with its own next-error.el
>     >     file?
>     > 
>     > We already have a minor mode for this: compilation-minor-mode.
> 
>     Yes, but the name "compilation-minor-mode" hardly addresses the DWIM
>     nature of next-error as it stands now, and the compilation-minor-mode
>     has other side effects (fontification, for instance).
> 
> Those go together because they are used together.
> 
> Introducing unnecessary levels of abstraction for small things
> creates clutter.  

I'm trying to make next-error a universal "next DWIM" interface, and
being tied to compilation-minor-mode will hamper that effort.  For
instance, it would look very strange if compilation-minor-mode was on
in a mail article summary, even though next-error (or some sensibly
named alias) could make sense for moving to the next article.  It
would be easier to name hooks for next-error, as well, if it had its
own mode.  I would like to create hooks that developers can easily use
to register their next-error capability, instead of the current
situation where next-error mode has to be enabled by magically setting
a variable, and discovering next-error buffers is an error-prone
algorithm.

I'm thinking of next-error-register and next-error-unregister
functions a developer would call in a buffer; to register a
next-error-function has to be provided (plus other things, probably)
and in return the buffer is registered as a next-error capable buffer.

Also, users will be less confused if next-error has its own minor
mode.

> We do not want a separate mode for next-error parsing alone,
> distinct from the rest of error handling.

Understood.  I would like to make next-error more than that.

Ted