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

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 5 Jun 2014 11:14:51 -0700 (PDT) Drew Adams <drew.adams@oracle.com> wrote: 

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.

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

DA> * Why mode-specific determination of locations etc. is relevant to the
DA>   request.
...
DA> You can use `next-error' from anywhere.  I want to be able to gather all
DA> `next-error' target locations and use them as completion candidates.

That's the request, as you said yourself shortly thereafter and I quoted :)

DA> * Why the request would require exposing any internals.

Because breaking `next-error-function' into two pieces (list locations
and move to them) as you suggest requires each mode to expose what it
considers "locations" to you and stick to that contract when the
locations are visited externally.

It also dictates that calling `next-error' means to move to a location,
whereas modes and users currently are free to do other things when
`next-error' is called.

It's just my opinion, so I hope others have feedback for you as well.

Ted