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

Previous Next

Package: emacs;

Reported by: Drew Adams <drew.adams <at> oracle.com>

Date: Sat, 3 May 2014 04:32:01 UTC

Severity: wishlist

Tags: wontfix

Found in version 24.4.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17394 in the body.
You can then email your comments to 17394 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#17394; Package emacs. (Sat, 03 May 2014 04:32:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Drew Adams <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 03 May 2014 04:32:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; enhancement request: split `next-error-function'
 functionality in two
Date: Fri, 2 May 2014 21:30:41 -0700 (PDT)
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 <at> 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''




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17394; Package emacs. (Sat, 03 May 2014 21:39:01 GMT) Full text and rfc822 format available.

Message #8 received at 17394 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 17394 <at> debbugs.gnu.org
Subject: RE: bug#17394: 24.4.50; enhancement request: split
 `next-error-function' functionality in two
Date: Sat, 3 May 2014 14:38:43 -0700 (PDT)
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.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17394; Package emacs. (Sat, 03 May 2014 21:42:02 GMT) Full text and rfc822 format available.

Message #11 received at 17394 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 17394 <at> debbugs.gnu.org
Subject: RE: bug#17394: 24.4.50; enhancement request: split
 `next-error-function' functionality in two
Date: Sat, 3 May 2014 14:41:48 -0700 (PDT)
> Needless to say, this bug is present also in the 24.4 pretest.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17394; Package emacs. (Thu, 05 Jun 2014 14:28:01 GMT) Full text and rfc822 format available.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17394: 24.4.50;
 enhancement request: split `next-error-function' functionality in two
Date: Thu, 05 Jun 2014 10:27:06 -0400
On Fri, 2 May 2014 21:30:41 -0700 (PDT) Drew Adams <drew.adams <at> 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17394; Package emacs. (Thu, 05 Jun 2014 18:16:01 GMT) Full text and rfc822 format available.

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org, 17394 <at> debbugs.gnu.org
Subject: RE: bug#17394: 24.4.50; enhancement request: split
 `next-error-function' functionality in two
Date: Thu, 5 Jun 2014 11:14:51 -0700 (PDT)
> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17394; Package emacs. (Thu, 05 Jun 2014 18:16:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17394; Package emacs. (Thu, 05 Jun 2014 21:26:02 GMT) Full text and rfc822 format available.

Message #23 received at 17394 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 17394 <at> debbugs.gnu.org
Subject: Re: bug#17394: 24.4.50;
 enhancement request: split `next-error-function' functionality in two
Date: Thu, 05 Jun 2014 17:25:42 -0400
On Thu, 5 Jun 2014 11:14:51 -0700 (PDT) Drew Adams <drew.adams <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17394; Package emacs. (Thu, 05 Jun 2014 21:53:01 GMT) Full text and rfc822 format available.

Message #26 received at 17394 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: 17394 <at> debbugs.gnu.org
Subject: RE: bug#17394: 24.4.50; enhancement request: split
 `next-error-function' functionality in two
Date: Thu, 5 Jun 2014 14:52:27 -0700 (PDT)
> 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".]




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17394; Package emacs. (Tue, 25 Jan 2022 14:30:03 GMT) Full text and rfc822 format available.

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#17394: 24.4.50; enhancement request: split
 `next-error-function' functionality in two
Date: Tue, 25 Jan 2022 15:28:48 +0100
Ted Zlatanov <tzz <at> 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




Added tag(s) wontfix. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 25 Jan 2022 14:30:04 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 17394 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 25 Jan 2022 14:30:04 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#17394; Package emacs. (Tue, 25 Jan 2022 16:18:01 GMT) Full text and rfc822 format available.

Message #36 received at 17394 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, "17394 <at> debbugs.gnu.org"
 <17394 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#17394: 24.4.50; enhancement request: split
 `next-error-function' functionality in two
Date: Tue, 25 Jan 2022 16:17:31 +0000
> Ted Zlatanov <tzz <at> 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.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 23 Feb 2022 12:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 34 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.