From: Dmitry Gutov <dgutov@yandex.ru>
To: Juri Linkov <juri@linkov.net>
Cc: 28864@debbugs.gnu.org, Noam Postavsky <npostavs@gmail.com>,
Tino Calancha <tino.calancha@gmail.com>
Subject: bug#28864: 25.3.50; next-error-no-select does select
Date: Mon, 23 Oct 2017 23:23:55 +0300 [thread overview]
Message-ID: <5c524170-7ba7-8279-41b5-b4286c2980f0@yandex.ru> (raw)
In-Reply-To: <87po9del14.fsf@localhost>
On 10/23/17 11:12 PM, Juri Linkov wrote:
> It's a step backward: it removes the ability to run several next-error
> navigations simultaneously. Currently it's possible to visit e.g.
> compilation results in one frame, and e.g. grep hits in another frame
> at the same time without affecting one another.
Why removes? Each buffer should keep its "current error" state, and
you'd switch between the navigations by switching to the
errors-containing buffer (and calling some additional command), probably.
> Undoubtedly, relying
> on the frame confines or on the buffer visibility is far from ideal.
I'm not married to buffer visibility, just figured it would be the
easiest to implement. And also, for the user to conceptualize.
If you implement switching between navigations even when all
error-containing buffers are still buried, more power to you.
> One solution that I proposed was to associate a window containing
> a navigated buffer with its next-error capable buffer, so that
> next-error issued in the same window will continue visiting other matches
> from the same next-error buffer (regardless whether it's hidden or not).
It's *a* solution, for sure. But there is little about a window that
indicates that an error-containing buffer is tied to it somehow, if it's
not displayed in it.
Implicit state is not so great as a UI.
> This assumes there will be a command to disassociate a window
> from its next-error buffer, and switch to another next-error buffer.
>
> Do you have a better idea?
Like I said: just adding a command that makes the current buffer the
next-error buffer. The user will have to switch to it, that may be an
extra step, but they'd have to specify the target buffer anyway, so
switching shouldn't make a lot of difference, keystroke-wise.
next prev parent reply other threads:[~2017-10-23 20:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-16 13:07 bug#28864: 25.3.50; next-error-no-select does select Tino Calancha
2017-10-17 13:37 ` Dmitry Gutov
2017-10-17 14:17 ` Tino Calancha
2017-10-18 7:44 ` Dmitry Gutov
2017-10-20 7:21 ` Tino Calancha
2017-10-20 21:49 ` Dmitry Gutov
2017-10-21 3:52 ` Tino Calancha
2017-10-22 20:32 ` Juri Linkov
2017-10-22 22:29 ` Dmitry Gutov
2017-10-23 20:12 ` Juri Linkov
2017-10-23 20:23 ` Dmitry Gutov [this message]
2017-10-24 20:22 ` Juri Linkov
2017-10-24 22:23 ` Dmitry Gutov
2017-10-25 23:58 ` Dmitry Gutov
2017-10-28 21:07 ` Juri Linkov
2017-10-28 22:46 ` Dmitry Gutov
2017-10-29 21:42 ` Juri Linkov
2017-10-30 14:59 ` Dmitry Gutov
2017-10-30 18:30 ` Eli Zaretskii
2017-10-30 21:13 ` Dmitry Gutov
2017-10-30 21:15 ` Juri Linkov
2017-10-30 21:14 ` Juri Linkov
2017-10-31 0:02 ` Dmitry Gutov
2017-10-31 21:56 ` Juri Linkov
2017-10-31 23:42 ` Dmitry Gutov
2017-11-02 22:00 ` Juri Linkov
2017-11-05 13:37 ` Dmitry Gutov
2017-11-06 21:41 ` Juri Linkov
2017-10-28 20:54 ` Juri Linkov
2017-10-28 22:42 ` 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
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=5c524170-7ba7-8279-41b5-b4286c2980f0@yandex.ru \
--to=dgutov@yandex.ru \
--cc=28864@debbugs.gnu.org \
--cc=juri@linkov.net \
--cc=npostavs@gmail.com \
--cc=tino.calancha@gmail.com \
/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).