[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17394: 24.4.50; enhancement request: split `next-error-function' fun
From: |
Drew Adams |
Subject: |
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".]