From: Ted Zlatanov <tzz@lifelogs.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 20489@debbugs.gnu.org
Subject: bug#20489: 25.0.50; next-error-find-buffer chooses non-current buffer without good reason
Date: Mon, 04 May 2015 18:33:56 -0400 [thread overview]
Message-ID: <87383c6kh7.fsf@lifelogs.com> (raw)
In-Reply-To: <5547F12F.2060809@yandex.ru> (Dmitry Gutov's message of "Tue, 5 May 2015 01:22:39 +0300")
On Tue, 5 May 2015 01:22:39 +0300 Dmitry Gutov <dgutov@yandex.ru> wrote:
DG> On 05/05/2015 01:03 AM, Ted Zlatanov wrote:
>> Then (1) can become "if one window on the selected frame has the highest
>> priority, return it."
DG> How will this help the user to control which error function to use next?
It doesn't help the user. It helps mode writers give their modes the
appropriate priority so the user doesn't have to know.
DG> And why the windows on the selected frame? If *compile* is buried,
DG> does it become useless? I'd say the opposite.
Perhaps? I am giving a suggestion, not a full implementation. The
essential thing is that we rank buffers, not just pick "the last one" or
the "one visible with 5 hieroglyphs" or whatever other DWIMmery we
currently use.
DG> Or suppose I have 4 windows open in the frame, and each one's buffer
DG> has a next-error-function that refers only to positions in the current
DG> file? And there's a *compile* buffer buried somewhere. How do I
DG> actually use the current buffer's next-error-function, aside from C-x
DG> 1?
Some history: I actually, long ago when `next-error' turned into a
navigation facility, we[1] had the idea of "meta next-error" which would
navigate one level higher than local. That would have made this whole
discussion, including rankings by priority, moot by simply saying "to
navigate between files (compile, grep) you use `meta-next-error' or
whatever it's called. to navigate inside file locations, use
`next-error'."
I was supposed to write a patch after the release but... the dog ate my
TODO list.
Perhaps you are interested in adapting that code instead of hacking on
the current scheme? Or should I retry implementing it? 9 years late is
not too bad, right? :)
If there's a time to implement this, I'd say it's now, before the 25.1
release, because it will break how many people expect `next-error' to
work. But OTOH I think it will improve the UI.
Thanks
Ted
[1] Lars, me, and others: https://lists.gnu.org/archive/html/emacs-devel/2006-04/msg00488.html
next prev parent reply other threads:[~2015-05-04 22:33 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87383c6kh7.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=20489@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
/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.