From: Dmitry Gutov <dgutov@yandex.ru>
To: Juri Linkov <juri@linkov.net>
Cc: 20489@debbugs.gnu.org
Subject: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason
Date: Sun, 31 Jan 2016 03:39:35 +0300 [thread overview]
Message-ID: <56AD57C7.5050809@yandex.ru> (raw)
In-Reply-To: <87si1etyyo.fsf@mail.linkov.net>
On 01/31/2016 02:43 AM, Juri Linkov wrote:
> I believe Eli meant this case because it's hard to imagine another one.
> So we have to find a solution for this case.
Let's not base the rest of the discussion on a guess, shall we?
In the message above, he was replying to my message, where I said: "On
the other hand, while *xref* is visible, `next-error' will keep working
for its results".
I can hardly imagine that in his counter-example, *xref* is hidden.
> By setting a window-local value of next-error-last-buffer in the
> selected window, we can continue the xref-navigation even when
> *compilation* is visible in an adjacent window.
Yes. But we _only_ continue it from the same window, which I do not
believe to be a good goal.
On the other hand, if we just use the global next-error-last-buffer
value, we'll just as well "continue the xref-navigation even when
*compilation* is visivle in an adjacent window".
>> But IMHO, (eq (length window-buffers) 1) is counter-intuitive: take the
>> configuration with three buffers with next-error-function set visible. Hide
>> the current last-buffer: nothing changes, `next-error' continues working as
>> it did. Hide the next one: and suddenly, `next-error' starts
>> behaving differently.
>
> When the number of next-error-function windows is more than one, then
> there's a dilemma which one to use.
Let's use the last one. That would definitely simplify things.
On the other hand, if we assign and read next-error-last-buffer value
via two accessor functions, anyone would be able to change the locality
of that value. You'd be able to use advice, to store it window-locally.
>> Your proposal _complicates_ the current state, making it more of
>> a problem. If the global value of next-error-last-buffer is used
>> consistently, at least the current state is easier to remember.
>
> But it allows the user to continue a paused navigation in another window
> in another frame, thus having several simultaneously active navigations
> in different windows.
If the "previous" navigation buffer is visible, you can also continue
navigation by going to it, and using one of the links there.
If it's not visible, it would make remembering which window belongs to
which navigation, even more difficult.
> What happens when two features set `next-error-function' at the same time?
> I guess the latest wins, so there is no problem no matter if using
> visibility of next-error-last-buffer or window-local values.
Yes, if next-error-function is set locally in a file buffer, we can only
see the last value.
But rather than "no problem", I'd say that neither approach to
visibility of next-error-last-buffer solves the Flycheck problem.
>> Since filing this bug, I've somewhat warmed up to using buffer visibility
>> as a condition to choose next-error-last-buffer.
>
> Visibility of next-error-last-buffer is not suitable for navigations
> without a navigational buffer.
Hence my proposal to equate the value nil of next-error-last-buffer with
"use the current buffer".
next prev parent reply other threads:[~2016-01-31 0:39 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-02 23:17 bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason Dmitry Gutov
2015-05-03 5:49 ` Stefan Monnier
2015-05-03 12:56 ` Dmitry Gutov
2015-05-04 22:03 ` Ted Zlatanov
2015-05-04 22:22 ` Dmitry Gutov
2015-05-04 22:33 ` Ted Zlatanov
2015-05-05 15:05 ` Dmitry Gutov
2015-05-05 15:15 ` Ted Zlatanov
2016-01-24 21:10 ` Juri Linkov
2016-01-25 6:23 ` Dmitry Gutov
2016-01-25 21:55 ` Juri Linkov
2016-01-25 23:36 ` Dmitry Gutov
2016-01-27 0:57 ` Juri Linkov
2016-01-27 2:43 ` Dmitry Gutov
2016-01-27 22:57 ` Juri Linkov
2016-01-27 23:28 ` Dmitry Gutov
2016-01-28 23:59 ` Juri Linkov
2016-01-29 0:35 ` Dmitry Gutov
2016-01-29 23:44 ` Juri Linkov
2016-01-30 0:57 ` Dmitry Gutov
2016-01-30 23:43 ` Juri Linkov
2016-01-31 0:39 ` Dmitry Gutov [this message]
2016-01-31 21:57 ` Juri Linkov
2016-01-31 22:38 ` Dmitry Gutov
2016-02-02 0:44 ` Juri Linkov
2016-02-02 1:40 ` Dmitry Gutov
2016-02-03 0:35 ` Juri Linkov
2016-02-04 1:00 ` Dmitry Gutov
2016-02-22 0:01 ` Dmitry Gutov
2016-02-22 17:22 ` Eli Zaretskii
2016-02-22 17:30 ` Dmitry Gutov
2016-02-22 17:39 ` Eli Zaretskii
2016-02-22 18:09 ` Dmitry Gutov
2016-02-22 18:11 ` Dmitry Gutov
2016-02-22 19:07 ` Eli Zaretskii
2016-02-27 10:14 ` Eli Zaretskii
2016-02-29 3:15 ` Dmitry Gutov
2016-02-29 16:23 ` Eli Zaretskii
2016-02-29 23:30 ` Dmitry Gutov
2017-11-06 21:53 ` Juri Linkov
2018-02-15 22:16 ` Juri Linkov
2018-02-27 1:21 ` Dmitry Gutov
2018-02-27 1:54 ` Dmitry Gutov
2018-02-27 18:07 ` Dmitry Gutov
2018-02-27 21:16 ` Juri Linkov
2018-02-28 2:13 ` Dmitry Gutov
2018-02-28 21:17 ` Juri Linkov
2018-03-02 1:19 ` Dmitry Gutov
2018-03-06 22:17 ` Juri Linkov
2018-03-07 14:11 ` Dmitry Gutov
2018-03-07 21:11 ` Juri Linkov
2018-03-12 22:08 ` Dmitry Gutov
2018-02-28 21:25 ` Juri Linkov
2018-03-01 22:58 ` Juri Linkov
2018-03-02 1:26 ` Dmitry Gutov
2018-03-06 22:25 ` Juri Linkov
2018-03-07 14:08 ` Dmitry Gutov
2018-03-07 21:03 ` Juri Linkov
2018-02-28 21:32 ` Juri Linkov
2018-03-02 0:54 ` Dmitry Gutov
2018-03-01 23:04 ` Juri Linkov
2018-03-02 1:30 ` Dmitry Gutov
2018-02-28 17:33 ` Richard Stallman
2018-02-21 21:30 ` Juri Linkov
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56AD57C7.5050809@yandex.ru \
--to=dgutov@yandex.ru \
--cc=20489@debbugs.gnu.org \
--cc=juri@linkov.net \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).