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

Previous Next

Full log

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

Previous Next

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