bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two

[Drew Adams <drew.adams@oracle.com>]

> DA> Enhancement request, to make the `next-error' feature, or more precisely
> DA> the buffers that offer it, more usable by other Lisp functions.
> ...
> DA> Essentially, I want a wrapper that provides a common interface to the
> DA> hit information that is stored in the different error buffers in
> DA> different ways.  AFAICT, there is no such feature today, but let me know
> DA> if I'm missing something obvious.  And let me know if this request is
> DA> not clear to you.
> 
> This may work for some modes but not others. The `next-error' facility
> is opaque to the caller because each mode has to decide what makes sense
> in terms of locations and motion to them. So I think trying to expose
> more of the internals and formalize them would limit the ways in which
> it can be useful.

I don't understand at least two things in what you wrote, Ted:

* Why mode-specific determination of locations etc. is relevant to the
  request.

* Why the request would require exposing any internals.

I want to have access to the go-to-target info in whatever buffer/mode,
whether it is a function or a location (e.g. buffer + marker) or
whatever, as data (e.g. an alist entry).

You can use `next-error' from anywhere.  I want to be able to gather all
`next-error' target locations and use them as completion candidates.
For that, I want, for example, an alist entry that includes the necessary
info: the target buffer and location (or location-finding function).

When I say "data", I mean just some Lisp entity that I can use to get
to the location in the given buffer (on demand, i.e., when the user
chooses a completion candidate).  It could be a function - it need
not be a passive data structure.

I do not want to *visit* all of the candidate locations just in order
to gather that info.  That's the point.

Here is one use of such a feature:
http://stackoverflow.com/questions/21125015/cycle-through-results-using-next-error-previous-error

In my case, I would provide an Icicles search multi-command that would
let you browse the `next-error' target candidates, narrowing to subsets
of them, jumping among them (i.e., visiting them) in any order, etc.