From: Juri Linkov <juri@linkov.net>
To: emacs-devel@gnu.org
Subject: next-error use cases
Date: Sun, 08 Apr 2018 00:47:42 +0300 [thread overview]
Message-ID: <87zi2esn7l.fsf@mail.linkov.net> (raw)
Several bug reports such as bug#20489 and bug#30674 revolve around
the uncertainty caused by unclear requirements for the next-error framework.
It would be helpful to identify possible scenarios to get a clearer picture of
what it's supposed to do.
The cornerstone of the whole feature is the function next-error-find-buffer
that returns a next-error capable buffer that defines next-error-function
to navigate to the next location.
Most fallbacks in next-error-find-buffer are fine in case the first condition
fails, but the main question is about the first condition itself: What is the
best default behavior for it? What other useful options it should provide?
What context should be used to select the right next-error-function buffer.
There are several alternatives of what buffer with next-error-function
should be selected after running next-error:
1. last next-error-function used anywhere globally
Pros: context-free, thus easier to understand
Cons: not WYSIWYG, i.e. in some cases produces unexpected results:
for example, after switching to another next-error-function buffer
will still continue the previous navigation from the hidden buffer
with last used next-error-function
2. next-error-function found in the current buffer
Cons: unexpected results when navigation visits another buffer with next-error-function,
e.g. when a ChangeLog file is visited by next-error from the *grep* buffer,
the next next-error should continue visiting grep hits, not ChangeLog entries.
(But when a next-error navigation never visited a next-error-function buffer, then
running `next-error' in a next-error-function buffer should use it unconditionally,
e.g. switching to a *compilation* buffer and running next-error should use it.)
3. next-error-function that visited the current buffer,
i.e. buffer-local value of next-error-last-buffer remembers the last used
next-error-function buffer in each visited buffer, and uses it for the next
next-error.
Cons: unexpected results when the same buffer is visited in different windows
from different next-error-function buffers
4. next-error-function that visited the buffer in the selected window
Pros: window-based logic gives more expected results
5. buffer with next-error-function visible in one of adjacent windows on the same frame
Pros: WYSIWYG
Cons: ambiguous when there are more than one window with next-error-function on the frame
What complicates matter more is that the value of next-error-function might
come from the same buffer where navigation occurs, i.e. unlike these cases
where next-error-function is defined in a special separate buffer:
compilation-next-error-function
xref--next-error-function
occur-next-error
change-log-next-error
diff-next-error
next-error-function can be defined in the same buffer, for example for:
flymake-goto-next-error
flyspell-goto-next-error
where the list of locations comes from the same buffer where next-error
navigates.
So the question is how one buffer can provide many next-error functions
by such different major/minor modes (flymake, flyspell) enabled in it
at the same time?
next reply other threads:[~2018-04-07 21:47 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-07 21:47 Juri Linkov [this message]
2018-04-08 13:48 ` next-error use cases Eli Zaretskii
2018-04-08 19:56 ` Juri Linkov
2018-04-08 20:26 ` Clément Pit-Claudel
2018-04-08 20:35 ` Dmitry Gutov
2018-04-10 4:19 ` Stephen Leake
2018-04-10 14:28 ` Drew Adams
2018-04-09 2:24 ` Eli Zaretskii
2018-04-08 20:36 ` Dmitry Gutov
2018-04-09 14:48 ` Eli Zaretskii
2018-04-09 18:44 ` Charles A. Roelli
2018-04-09 20:47 ` Juri Linkov
2018-04-10 4:24 ` Stephen Leake
2018-04-10 20:06 ` Juri Linkov
[not found] ` <86woxe1l0l.fsf@stephe-leake.org>
2018-04-11 7:29 ` Dmitry Gutov
2018-04-11 20:46 ` Juri Linkov
2018-04-12 15:31 ` Stephen Leake
2018-04-12 15:25 ` Stephen Leake
2018-04-12 16:51 ` Dmitry Gutov
2018-04-13 16:22 ` Stephen Leake
2018-04-13 16:26 ` Dmitry Gutov
2018-04-10 23:06 ` Dmitry Gutov
2018-04-12 20:27 ` Juri Linkov
2018-04-13 7:45 ` Eli Zaretskii
2018-04-13 19:48 ` Juri Linkov
2020-05-19 1:10 ` Dmitry Gutov
2020-05-19 22:12 ` Juri Linkov
2020-05-21 1:57 ` Dmitry Gutov
2020-05-21 20:33 ` Vladimir Sedach
2020-05-21 21:02 ` Stefan Monnier
2020-05-21 21:53 ` Dmitry Gutov
2020-05-21 22:06 ` Juri Linkov
2020-05-21 22:49 ` Dmitry Gutov
2020-05-22 1:31 ` Clément Pit-Claudel
2020-05-22 19:10 ` Vladimir Sedach
2020-05-23 1:22 ` Clément Pit-Claudel
2020-05-23 1:27 ` Dmitry Gutov
[not found] ` <b386929f-4412-860d-343f-a728d6d7e816@gmail.com>
[not found] ` <c6c941bb-a160-f767-b266-6a17f4b4c2ca@yandex.ru>
[not found] ` <152f1200-a2d0-e137-418f-18ceb14fbbe3@gmail.com>
2020-05-23 15:29 ` Drew Adams
2020-05-24 1:36 ` Dmitry Gutov
2020-05-24 1:41 ` Clément Pit-Claudel
2020-05-24 14:25 ` Dmitry Gutov
2020-05-22 23:50 ` Dmitry Gutov
2020-05-23 1:25 ` Clément Pit-Claudel
2020-05-23 1:29 ` Dmitry Gutov
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=87zi2esn7l.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=emacs-devel@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.