unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.






  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).