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

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

[Drew Adams]

Enhancement request, to make the `next-error' feature, or more precisely
the buffers that offer it, more usable by other Lisp functions.

Currently, buffers, such as `occur' and `grep', that provide
`next-error' information hold the destination information for each hit
in different ways, and they provide a function for the buffer-local
value of `next-error-function' that does two things together:

1. Get the destination information for the next (or previous) hit,
   e.g. based on point in the search-hits buffer.

2. Go to that search-hit destination.

What I would like to see is a buffer-local variable whose value is a
function that does only #1.  (This var would then be used by a function
that is the value of `next-error function', to do its #1 part.)

Why?  Because instead of just going to the "next" or "previous" hit, I
want to gather all of the hits at once, to serve as candidates
(e.g. completion candidates) for another way of choosing and navigating
among them (e.g. in different orders besides "next" in the hit list).

(I sometimes want to in fact visit the target buffers during a #1
function call and pick up some text at or near the hit position to serve
as the candidate text, if what is in the error buffer does not provide
the best context for choosing.  But all I'm really asking for here is to
get the search-hit destinations (locations).)

This is easy enough to do for each particular buffer and mode such as
occur or grep separately, but each one is different.  The point of
variable `next-error-function' is to provide a common interface: just
call the value of that function to do #1 and #2 - no need to know how
the given search-hit buffer represents/maps the hit information.

When I call the function (the value of the new variable) to do #1, I
just want it to return the information for the next hit (its location).
I do not want to actually visit the hit at that time for the user,
displaying and raising the destination buffer etc.  I want to gather
the destination information for each of the hits, and in a
buffer/mode-independent way.

Essentially, I want a wrapper that provides a common interface to the
hit information that is stored in the different error buffers in
different ways.  AFAICT, there is no such feature today, but let me know
if I'm missing something obvious.  And let me know if this request is
not clear to you.


In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-04-29 on ODIEONE
Bzr revision: 117031 monnier@iro.umontreal.ca-20140429151607-qnkgbymwfaj5ut08
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

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

[Drew Adams]

Needless to say, this bug is present also in the 24.4 pretest.

(I am using this development version at Stefan's request, to try
to catch the crash of bug #17340 with his patch.)

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

[Drew Adams]

> Needless to say, this bug is present also in the 24.4 pretest.

Sorry, that was meant for #17397, not #17394.

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

[Ted Zlatanov]

On Fri, 2 May 2014 21:30:41 -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.

Ted

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

[Drew Adams]

> 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.

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

[Ted Zlatanov]

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

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

[Drew Adams]

> 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 :)

Sorry, I don't understand your reply.

> 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.

See below, wrt bookmarks.  (Or think Emacs file handlers.)  There is
nothing particularly constraining about providing a Lisp representation
of (getting to) a potential target (destination/location).

> 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.

I agree that "location" can mean pretty much anything - just as it does,
for example, for "jumping" to a bookmark "location".  That does not stop
bookmarks from recording such destinations - either extensively/explicitly,
as traditional locations, or intensively/implicitly, as handler functions.
An Emacs bookmark can do anything at all.  It needs only (a) a name and
(b) info sufficient to allow carrying out the intended effect.

Nothing in what I suggested requires `next-error' to in fact literally
"move to a location".  The requirement is for a representation of the
effect (whether we call it "location" or something else).

A representation that provides" (a) a user-recognizable component
(name/label - something you can recognize and choose) and (b) the
associated effect: something that can be used by Lisp code to bring
about the effect.

For an explicit location, (b) might be a buffer or file and a position
in it (a number or marker), and (a) might be some text at or near that
location.  But the request in no way imposes this as a limitation.
Again, think bookmarks.

[A bookmark, whose the data is recorded persistently, can be used long
after it was defined and in a context that has changed since.  Even so,
Emacs can typically find the location.  This should be even less of a
problem (and typically not a problem at all, I expect) for `next-error'
"locations".]

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

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> 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.

Skimming this thread, I agree, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
> > 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.
> 
> Skimming this thread, I agree, so I'm closing this bug report.

This is _really_ too bad.  This has nothing
whatsoever to do with any "internals".

There's no difficulty in providing a means
for a mode to offer Lisp access to the
locations, and there's no problem in letting
a mode not do that.  Not every mode needs to
offer this usability.

This enhancement would provide an important,
useful feature.  It's sad that you don't see
that, but I expect that in another decade or
two Emacs will provide this, or similar.