conflicting uses of next-error-function (was: UI inconveniences with M-.)

[Stefan Monnier]

> Dmitry took that out because he thinks that it interferes too much with
> compilation-mode.  Maybe he's right but let me note that M-x rgrep also
> uses next-error/prev-error and similarly interferes with
> compilation-mode.

Indeed, I've occasionally been annoyed by conflicting uses of
next-error-last-buffer/next-error-function.  And in both directions:
sometimes I don't want `grep' to hijack my ongoing traversal of
compiler warnings, and sometimes I regret that some other package
doesn't let me use C-x `

Maybe we should consider refining this so that all package which can
sometimes benefit from C-x ` would feel free to provide support for
next-error, without the fear of imposing themselves.  For that, the
next-error framework needs to make it possible for the user to control
which package gets to really use next-error and when.

Not sure what that should look like, tho.  Maybe some config var could
specify which packages's next-error-support is "enabled" by default,
then some way for the user to override that default on a case by case
basis: e.g. a command to run inside the *xref* buffer would
"force-enable" the next-error support for this one time, and maybe
a new `next-error-pop-context' command would go back to the previous
"next-error-last-buffer/function"?


        Stefan