From: martin rudalics <rudalics@gmx.at>
To: Drew Adams <drew.adams@oracle.com>,
Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,
"16767@debbugs.gnu.org" <16767@debbugs.gnu.org>
Subject: bug#16767: [External] : bug#16767: 24.3.50; `C-x 5 b' for special-display buffers
Date: Wed, 8 Sep 2021 10:27:54 +0200 [thread overview]
Message-ID: <73026fca-0b01-6e3f-5ab4-1c25ff848a13@gmx.at> (raw)
In-Reply-To: <SJ0PR10MB548810A6E4DE32FE2515B8C8F3D39@SJ0PR10MB5488.namprd10.prod.outlook.com>
> You can say that the `special-display-*' options
> override default behavior, and of course they do.
> But nothing says that they override THAT behavior,
> of using a separate frame. Nothing in the doc,
> AFAICT.
You've been customizing the option `special-display-regexps' which
specifies a
List of regexps saying which buffers should be displayed specially.
in a way to display *scratch* specially. The doc-string of that option
continues saying that
Displaying a buffer with `display-buffer' or `pop-to-buffer', if
any regexp in this list matches its name, displays it specially
using `special-display-function'. `special-display-popup-frame'
\(the default for `special-display-function') usually displays
the buffer in a separate frame made with the parameters specified
by `special-display-frame-alist'.
and since you have not customized `special-display-function' and the
doc-string of `special-display-popup-frame' tells to
Pop up a frame displaying BUFFER and return its window.
If BUFFER is already displayed in a visible or iconified frame,
raise that frame.
C-x 5 b which runs `switch-to-buffer-other-frame' whose doc-string says
This uses the function `display-buffer' as a subroutine to
display the buffer; see its documentation for additional
customization information.
uses the selected window which displays *scratch* already and makes sure
that its frame is risen.
> All they do is say that the given buffers use
> frames with particular frame parameters. They
> say nothing at all about the use of a same frame
> or a different frame. And that means (should
> mean) that the default behavior described for
> the functions cited should remain the case,
> except for the behavior (e.g. frame parameters)
> prescribed by the `special-display-*' options.
> Those options say nothing at all about using
> another or the same frame.
The doc-string of `special-display-popup-frame' says that.
> They say nothing at
> all about `C-x 5' behavior.
The doc-string of `switch-to-buffer-other-frame' says that.
> What's needed is a way to NOT have prefix key
> `C-x 5' use the same window for some specified
> set of buffers. Or (better) to have `C-x 5'
> keys NOT use the same window for ANY buffers.
The default behavior does that. You override it with your
customizations.
> The default behavior for special-display-*
> is to reuse any window that already
> displays the buffer, so in order to make
> C-x 5 2 meaningful we'd clearly want to skip
> this part of the usual special-display-*
> behavior.
So you were aware of the fact that C-x 5 2 behaves like that all the
time and yet insisted that our code and/or docs are wrong? Do you ever
think that going through your bug reports takes peoples' time?
martin
next prev parent reply other threads:[~2021-09-08 8:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-15 22:29 bug#16767: 24.3.50; `C-x 5 b' for special-display buffers Drew Adams
2014-02-16 10:32 ` martin rudalics
2014-02-16 16:57 ` Drew Adams
2014-02-16 17:14 ` martin rudalics
2014-02-16 17:16 ` Drew Adams
2021-09-06 9:27 ` Lars Ingebrigtsen
2021-09-06 14:08 ` martin rudalics
2021-09-06 15:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-06 19:08 ` martin rudalics
2021-09-07 8:15 ` martin rudalics
2021-09-07 15:04 ` Lars Ingebrigtsen
2021-09-07 15:44 ` bug#16767: [External] : " Drew Adams
2021-09-07 17:26 ` martin rudalics
2021-09-07 19:12 ` Drew Adams
2021-09-08 8:27 ` martin rudalics [this message]
2021-09-08 16:34 ` 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=73026fca-0b01-6e3f-5ab4-1c25ff848a13@gmx.at \
--to=rudalics@gmx.at \
--cc=16767@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
/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.