From: "Drew Adams" <drew.adams@oracle.com>
To: "'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 8865@debbugs.gnu.org
Subject: bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames'
Date: Fri, 17 Jun 2011 08:08:35 -0700 [thread overview]
Message-ID: <134D56CC977B4CB289C6F019A73A5F2D@us.oracle.com> (raw)
In-Reply-To: <jwv39j9qj12.fsf-monnier+emacs@gnu.org>
> >> Depends on the intention behind that test, I guess.
> > The intention of that test has to be to determine whether
> > `pop-up-frames' is nil or non-nil, since that was the
> > original design of `pop-up-frames'.
>
> You're describing the test, not its intention.
The intention has to include what happens - what the test does, or else the
intention was not correctly realized in practice.
My question was about replacing such a test. The common denominator of the
intentions behind using such tests is what all of those tests do (have in
common): distinguish nil `pop-up-frames' from non-nil. Nothing more.
The behavior that results from distinguishing nil from non-nil `pop-to-frames'
prior to Martin's changes is the behavior I want to reproduce after Martin's
changes.
If it is not enough now (to get the same behavior as before) to just test
`pop-up-frames' for nil/non-nil, or if there is a new preferred way, then I want
to use that new alternative (with Emacs 24).
In sum, if you say "X is deprecated" or no longer recommended then please add
"Use Y instead", where you are _specific_ about how to accomplish the _same_
thing.
That does not mean just saying "Use `display-buffer-alist' instead of
`pop-up-frames', if there is no obvious one-to-one mapping.
That is all we say currently in the "This variable is obsolete" guidance. It
might be enough for there, but I'm asking for more explanation/detail/guidance.
As Martin replied to Thierry vis-a-vis his figuring out `display-buffer-alist'
in its relation to `pop-to-buffer': "I didn't expect anyone even to try to
understand this." Likewise for its relation to `pop-up-frames': a little more
explanation is in order, to guide users.
> > Non-nil was designed to mean that `display-buffer' uses
> > another frame.
>
> Actually, it's a bit more complex than that, since display-buffer may
> use another frame even if pop-up-frames is nil (e.g. via
> special-display-buffer-names), or it may use the same frame even when
> pop-up-frames is non-nil, e.g. if it's already displayed.
I was being succinct, as in the first line of the doc string:
"Whether `display-buffer' should make a separate frame."
But I also went into more detail, just as you do.
> Do you have some example to point to, so we can try and see what new
> predicate to define to provided the needed info?
See my reply to Martin.
next prev parent reply other threads:[~2011-06-17 15:08 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-14 18:14 bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames' Drew Adams
2011-06-14 19:08 ` martin rudalics
2011-06-14 19:43 ` Drew Adams
2011-06-15 9:24 ` martin rudalics
2011-06-15 16:14 ` Drew Adams
2011-06-15 16:26 ` martin rudalics
2011-06-15 17:11 ` Drew Adams
2011-06-15 17:44 ` martin rudalics
2011-06-15 17:53 ` Drew Adams
2011-06-15 22:15 ` Drew Adams
2011-06-16 13:01 ` martin rudalics
2011-06-16 14:01 ` Drew Adams
2011-06-16 15:08 ` martin rudalics
2011-06-16 16:03 ` Drew Adams
2011-06-17 15:46 ` martin rudalics
2011-06-17 18:31 ` Drew Adams
2011-06-19 17:43 ` Drew Adams
2011-06-19 18:50 ` martin rudalics
2011-06-19 20:13 ` Drew Adams
2011-06-16 13:09 ` Stefan Monnier
2011-06-16 14:02 ` Drew Adams
2011-06-17 2:44 ` Stefan Monnier
2011-06-17 15:08 ` Drew Adams [this message]
2011-06-17 16:21 ` Stefan Monnier
2011-06-17 18:31 ` Drew Adams
2011-06-17 21:46 ` Stefan Monnier
2011-06-17 23:55 ` Drew Adams
2011-06-18 1:51 ` Stefan Monnier
2011-06-16 8:45 ` martin rudalics
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=134D56CC977B4CB289C6F019A73A5F2D@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=8865@debbugs.gnu.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 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).