bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames'


From: Drew Adams
Subject: bug#8865: 24.0.50; `display-buffer' does not respect `pop-up-frames'
Date: Fri, 17 Jun 2011 08:08:35 -0700

> >> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]