From: Drew Adams <drew.adams@oracle.com>
To: 17394@debbugs.gnu.org
Subject: bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two
Date: Fri, 2 May 2014 21:30:41 -0700 (PDT) [thread overview]
Message-ID: <1257238c-02c2-48f6-a4f1-c53674f87734@default> (raw)
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''
next reply other threads:[~2014-05-03 4:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-03 4:30 Drew Adams [this message]
2014-05-03 21:38 ` bug#17394: 24.4.50; enhancement request: split `next-error-function' functionality in two Drew Adams
2014-05-03 21:41 ` Drew Adams
2014-06-05 14:27 ` Ted Zlatanov
2014-06-05 18:14 ` Drew Adams
2014-06-05 21:25 ` Ted Zlatanov
2014-06-05 21:52 ` Drew Adams
2022-01-25 14:28 ` Lars Ingebrigtsen
2022-01-25 16:17 ` bug#17394: [External] : " Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1257238c-02c2-48f6-a4f1-c53674f87734@default \
--to=drew.adams@oracle.com \
--cc=17394@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.