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

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

[Drew Adams]

My setup, not emacs -Q.

Summary: A non-interactive call to `display-buffer' with non-nil arg
NOT-THIS-WINDOW does not show the buffer in a separate frame, even though
`pop-up-frames' is non-nil.
 
I have non-nil `pop-up-frames'.  I use the following function via `M-x
find-library-other-window frame.el'.  It should find the library in a
separate frame.  Instead, it finds it in another window of the current
frame - i.e., it splits the current window and puts it in one of those
two windows.
 
(defun find-library-other-window (library)
  "Find the Emacs-Lisp source of LIBRARY in another window."
  (interactive
   (let* ((path (cons (or find-function-source-path load-path)
        (find-library-suffixes)))
   (def (if (eq (function-called-at-point) 'require)
     (save-excursion (backward-up-list)
                                   (forward-char)
                                   (backward-sexp -2)
                                   (thing-at-point 'symbol))
   (thing-at-point 'symbol))))
     (when def (setq def (and (locate-file-completion def path 'test) def)))
     (list (completing-read "Library name: " 'locate-file-completion
                            path nil nil nil def))))
  (let ((buf (find-file-noselect (find-library-name library))))
    (pop-to-buffer buf 'other-window)))
 
Invoking `M-x find-library-other-window frame.el' leads to the following
call chain (from the debugger):
 
(display-buffer #<buffer frame.el> other-window nil)
 
(display-buffer-normalize-specifiers "frame.el" other-window nil)
returns the following sexp, which I'll call FOO below:
 
((reuse-window other same visible)
 (pop-up-window (largest) (lru))
 (pop-up-frame)
 (reuse-window other other visible)
 (reuse-window nil same 0)
 (reuse-window-even-sizes . t)
 (pop-up-frame t)
 (pop-up-frame-function lambda nil (make-frame pop-up-frame-alist))
 (reuse-window nil same visible)
 (pop-up-window (largest) (lru))
 (pop-up-frame)
 (reuse-window nil other visible)
 (reuse-window-even-sizes . t)
 (reuse-window nil same visible)
 (pop-up-window (largest) (lru))
 (pop-up-frame)
 (pop-up-frame-alist (height . 24) (width . 80) (unsplittable . t))
 (reuse-window nil other visible)
 (reuse-window-even-sizes . t))
 
Then, * display-buffer-reuse-window(
#<buffer frame.el> 
(other same visible)
FOO)
 
returns: nil
 
Then, * display-buffer-pop-up-window(
#<buffer frame.el>
((largest) (lru))
FOO)
 
calls * display-buffer-split-window(
#<window 8 on drews-lisp-20> 
nil
FOO)
 
which calls * display-buffer-split-window-1(
#<window 8 on drews-lisp-20> below 4)
 
which calls * split-window(
#<window 8 on drews-lisp-20> nil below)
 
which calls * resize-this-window(
#<window 8 on drews-lisp-20> -29 nil)
 
which calls * split-window-internal(
#<window 8 on drews-lisp-20> 29 below 0.5)
 
which splits the window and then throws, putting the frame.el buffer in
the second window (instead of its own frame).
 
 
 

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-06-13 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/build/include'
 

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

[martin rudalics]

 > I have non-nil `pop-up-frames'.  I use the following function via `M-x
 > find-library-other-window frame.el'.  It should find the library in a
 > separate frame.  Instead, it finds it in another window of the current
 > frame - i.e., it splits the current window and puts it in one of those
 > two windows.

Emacs has a lot of commands postfixed with -other-window and
-other-frame.  For example, `find-file-other-window' or
`switch-to-buffer-other-window' traditionally find a file or switch to a
buffer in another window on the same frame.  By this convention,
`find-library-other-window' is not supposed to pop up a new frame.

If we want to maintain compatibility with the old behavior in this and
similar cases we'd have to segregate a set of reserved values for the
second argument of `display-buffer'.  Preserving the classic "non-nil"
behavior is impossible if we want to use the new `display-buffer' code
(originally I favored let-binding to achieve that behavior but using an
argument was proposed by Stefan Monnier and overloading the second
argument by Juri Linkov - at the time that was discussed there were no
objections).

I have no objections interpreting the argument value `t' in the sense
that when `pop-up-frames' is non-nil and not unset, `display-buffer'
tries to pop up a new frame before it tries to pop up a new window.

martin

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

[Drew Adams]

>  > I have non-nil `pop-up-frames'.  I use the following 
>  > function via `M-x find-library-other-window frame.el'.
>  > It should find the library in a separate frame.
>  > Instead, it finds it in another window of the current
>  > frame - i.e., it splits the current window and puts it in 
>  > one of those two windows.
> 
> Emacs has a lot of commands postfixed with -other-window and
> -other-frame.  For example, `find-file-other-window' or
> `switch-to-buffer-other-window' traditionally find a file or 
> switch to a buffer in another window on the same frame.

Yes, and they all pop up a separate frame, if `pop-up-frames' is non-nil.  This
has _always_ been the case, ever since Emacs introduced frames.  And it should
continue to be the case.

And the doc of `pop-up-frames' (in (elisp) Choosing Window) says so:

 This variable specifies whether `display-buffer' should make new
 frames.  If it is non-`nil', `display-buffer' looks for a window
 already displaying ... If it finds such a window...
 Otherwise it makes a new frame...

Otherwise it makes a new frame.  Period.

And it says, further reinforcing the point:

 If `pop-up-frames' is `nil', then `display-buffer' either
 splits a window or reuses one.

It does that only if the option value is nil.

But in the latest build, this is broken.  Try, in last weeks build (or last
year's or 1990's build or...):

emacs -Q
(setq pop-up-frames t)
C-x 4 f foo.el

The file is visited in a separate frame.  Not so in this week's build.  The same
is true for _all_ `C-x 4' prefix commands.  Non-nil `pop-up-frames' treats all
`C-x 4' keys as if they were `C-x 5' keys.  It makes `*-other-window' commands
behave as `*-other-frame' commands.  Always has.  Always should.

> By this convention,
> `find-library-other-window' is not supposed to pop up a new frame.

Of course it is.  Just like all the others.

> If we want to maintain compatibility with the old behavior in this and
> similar cases we'd have to segregate a set of reserved values for the
> second argument of `display-buffer'.  Preserving the classic "non-nil"
> behavior is impossible if we want to use the new `display-buffer' code

If it ain't broke, don't fix it.  If there are some problems that you would like
to fix for people who do not use non-nil `pop-up-frames', do so, but not by
breaking Emacs for people who do use non-nil `pop-up-frames', please.

> (originally I favored let-binding to achieve that behavior 
> but using an
> argument was proposed by Stefan Monnier and overloading the second
> argument by Juri Linkov - at the time that was discussed there were no
> objections).

I have nothing to say about how to implement your new features.  My point is to
please not, as a side effect, also break Emacs for non-nil `pop-up-frames'.

> I have no objections interpreting the argument value `t' in the sense
> that when `pop-up-frames' is non-nil and not unset, `display-buffer'
> tries to pop up a new frame before it tries to pop up a new window.

I'm not sure I understand what you're saying (what argument? etc.).  But if you
are saying that you will restore the behavior that non-nil `pop-up-frames'
causes `display-buffer' to do what the doc says it should do, and what it always
has done, then yes, I'm in favor of that.  That means:

 `display-buffer' looks for a window already displaying
 BUFFER-OR-NAME on any visible or iconified frame. If it finds such
 a window, it makes that window's frame visible and raises it if
 necessary, and returns the window.  Otherwise it makes a new frame,
 unless the variable's value is `graphic-only' and the selected
 frame is not on a graphic display.

(Non-nil is not the same as non-t, BTW, for both `pop-up-frames' and the
NOT-THIS-WINDOW arg of `display-buffer'.  If you were speaking about that arg,
then any non-nil value has always had the same behavior as a value of t.  Or if
you were speaking of `pop-up-frames', then the only special non-nil value is
`graphic-only', not t, and even that value is special only for non-graphic
displays.)

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

[martin rudalics]

 > (Non-nil is not the same as non-t, BTW, for both `pop-up-frames' and the
 > NOT-THIS-WINDOW arg of `display-buffer'.  If you were speaking about that arg,
 > then any non-nil value has always had the same behavior as a value of
 > t.

This is no more the case.  That argument is called SPECIFIERS now and
certain values (like lists and certain symbols) will be reserved for a
different behavior.  If you don't like such a change, you will have to
talk to someone else; I already mentioned Juri and Stefan as potential
addressees.

Meanwhile I can offer the below substitute for
`display-buffer-normalize-specifiers-1' which should address most of
your concerns in this area.

martin


(defun display-buffer-normalize-specifiers-1 (specifiers)
   "Subroutine of `display-buffer-normalize-specifiers'.
SPECIFIERS is the SPECIFIERS argument of `display-buffer'."
   (let (normalized entry)
     (cond
      ((not specifiers)
       nil)
      ((listp specifiers)
       ;; If SPECIFIERS is a list, we assume it is a list of specifiers.
       (dolist (specifier specifiers)
	(cond
	 ((consp specifier)
	  (setq normalized (cons specifier normalized)))
	 ((symbolp specifier)
	  ;; Might be a macro specifier, try to expand it (the cdr is a
	  ;; list and we have to reverse it later, so do it one at a
	  ;; time).
	  (let ((entry (assq specifier display-buffer-macro-specifiers)))
	    (dolist (item (cdr entry))
	      (setq normalized (cons item normalized)))))))
       ;; Reverse list.
       (nreverse normalized))
      ((and (not (eq specifiers 'other-window))
	   (setq entry (assq specifiers display-buffer-macro-specifiers)))
       ;; A macro specifier.
       (cdr entry))
      ((memq pop-up-frames '(nil unset))
       ;; Pop up a new window.
       (cdr (assq 'other-window display-buffer-macro-specifiers)))
      (t
       ;; Pop up a new frame.
       (cdr (assq 'other-frame display-buffer-macro-specifiers))))))

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

[Drew Adams]

>  > (Non-nil is not the same as non-t, BTW, for both 
>  > `pop-up-frames' and the NOT-THIS-WINDOW arg of `display-buffer'.
>  > If you were speaking about that arg, then any non-nil value
>  > has always had the same behavior as a value of t...)
> 
> This is no more the case.  That argument is called SPECIFIERS now and
> certain values (like lists and certain symbols) will be reserved for a
> different behavior.  If you don't like such a change, you will have to
> talk to someone else; I already mentioned Juri and Stefan as potential
> addressees.
> 
> Meanwhile I can offer the below substitute for
> `display-buffer-normalize-specifiers-1' which should address most of
> your concerns in this area.

1. The text you quoted from me was only a parenthetical remark -- see the "BTW",
plus the parens.  I hope that your reply to it does not constitute your complete
response to this bug report.  The bug is described clearly, outside of and
independent of that remark.

2. Anyway, I tried your proposed redefinition of
`display-buffer-normalize-specifiers-1', just in case, and it does not have any
effect on this bug.  See below: the `other-window' value is not something
special in my code, and the fix is certainly not to treat that particular symbol
as a special case.

3. If users must change all of their existing calls of the form
(display-buffer buf 'SOMETHING-NON-NIL), to keep the same behavior as before,
then you need to explicitly say so - in the doc.  I don't mind doing that,
personally, but I need to know just what the correct change is.  Other users are
in the same boat.

FWIW, the only reason I have sometimes used a value such as a symbol
`other-window' or `OTHER-WIN' instead of `t' in cases like this is to make the
code a little more readable - it's just a reminder of what a non-nil arg does
here.  So there is nothing special in my use of `other-window' as the value, and
I don't have any problem with changing such non-nil values to something else (to
`t'?).

4. But is that really necessary, for you to make the changes that you need?
That's for you to answer, but here are some thoughts that I hope will help.

Wrt the general question of changing parameter values such as this one, i.e.,
defining new, specific non-nil values where previously all non-nil values were
treated the same:

The usual approach, and a better one in general, is to allow for the new
treatment of specific non-nil values, but to still treat any other non-nil value
the same as before.  IOW, a priori I'm not wild about your _design_ choice of
changing the meaning of arbitrary (non-specific) values.  Why not just handle
the specific values you want/need to handle, and let any other non-nil value do
what it has always done?

5. In the case of `display-buffer', I can see that you want to handle a _list_
of SPECIFIERS, but why also introduce the "convenience" of also handling
arbitrary non-list values as specifiers?  Why not just interpret a list as
SPECIFIERS?  That would certainly break less code, since the most common non-nil
values in use are probably symbols.

6. A more important question would be why not, instead of completely changing
the meaning of the second parameter, add a new (optional) parameter for your
SPECIFIERS needs?  I know you said that Juri suggested to reuse the second
parameter (NOT-THIS-WINDOW) for this, but that doesn't seem like such a great
idea.  That's not reuse; it's just a recipe for breaking code.

7. Anyway, this ("any non-nil value has always had the same behavior as a value
of t") is just a side discussion wrt the bug reported.  Please do not lose sight
of the bug itself, whatever you decide about this side issue.

It is particularly important that you understand, as you apparently did not when
you designed this change, that non-nil `pop-up-frames' makes all
`*-other-window' functions use another frame, not another window.  It is an
important Emacs feature that it is enough that a user customize `pop-up-frames'
to non-nil, to make all other-window commands (e.g. `C-x 4' prefix) behave as
other-frame commands (`C-x 5' prefix).

Please DTRT.  Thx.

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

[martin rudalics]

 > 2. Anyway, I tried your proposed redefinition of
 > `display-buffer-normalize-specifiers-1', just in case, and it does not have any
 > effect on this bug.  See below: the `other-window' value is not something
 > special in my code, and the fix is certainly not to treat that particular symbol
 > as a special case.

With the redefinition of `display-buffer-normalize-specifiers-1' doing

(let ((pop-up-frames t))
   (display-buffer (get-buffer-create "*foo*") 'other-window))

pops up a new frame.  So do

(let ((pop-up-frames t))
   (display-buffer (get-buffer-create "*foo*") 4))

and

(let ((pop-up-frames t))
   (display-buffer (get-buffer-create "*foo*") "Drew"))

Evaluating

(setq pop-up-frames t)

and subsequently doing C-x 4 b pops up the buffer in a new frame.  What
do you get?  What more do you want?

martin

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

[Drew Adams]

> With the redefinition of `display-buffer-normalize-specifiers-1'...
> subsequently doing C-x 4 b pops up the buffer in a new frame.

Yes, it does.  I was mistaken about that (I confused this bug with another).

But are you proposing to redefine `display-buffer-normalize-specifiers-1' that
way for Emacs, or are you just proposing that I redefine it locally for myself
that way?

The latter would not address (fix) the bug.  Users (not just me) should not have
`C-x 4 f' etc. change its behavior - those commands should still use another
frame (for non-nil `pop-up-frames'), as they have always done.

If you implement this change in Emacs, then yes, please close the bug, as your
redefinition seems to fix it.

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

[martin rudalics]

 > But are you proposing to redefine `display-buffer-normalize-specifiers-1' that
 > way for Emacs, or are you just proposing that I redefine it locally for myself
 > that way?

The former.

 > If you implement this change in Emacs, then yes, please close the bug, as your
 > redefinition seems to fix it.

I'll do that tomorrow.  Meanwhile keep it in your window.el until Sean
has made the new binaries.  I hope to fix also the special-display bug
till then.

martin

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

[Drew Adams]

>  > If you implement this change in Emacs, then yes, please 
>  > close the bug, as your redefinition seems to fix it.
> 
> I'll do that tomorrow.  Meanwhile keep it in your window.el until Sean
> has made the new binaries.  I hope to fix also the special-display bug
> till then.

Thank you, Martin, especially for the latter bug.
It is that one that makes the latest build unusable for me.

No special hurry, BTW - I don't need to work with the latest build.

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

[Drew Adams]

BTW, can you tell me what is a reasonable substitute for tests of
`pop-up-frames' now?  That is, what to do about code that has (if pop-up-frames
...)?  What is the replacement for such a test in Emacs 24?  Thx.

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

[martin rudalics]

Fixed on trunk in revision 104603.

martin

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

[martin rudalics]

 > BTW, can you tell me what is a reasonable substitute for tests of
 > `pop-up-frames' now?  That is, what to do about code that has (if pop-up-frames
 > ...)?  What is the replacement for such a test in Emacs 24?  Thx.

Please decide together with David Engster where to bring the current
discussion of bug#8857 to and try to give it an appropriate title.  I
can't find the idiom

(if pop-up-frames

in the current trunk so I would first like to know why and how it is
used.  `sunrise-sunset' uses

                     (if pop-up-windows

but I'm quite confident that this is not TRT to do.

martin

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

[Stefan Monnier]

> BTW, can you tell me what is a reasonable substitute for tests of
> `pop-up-frames' now?  That is, what to do about code that has (if
> pop-up-frames ...)?  What is the replacement for such a test in Emacs
> 24?  Thx.

Depends on the intention behind that test, I guess.


        Stefan

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

[Drew Adams]

>  > BTW, can you tell me what is a reasonable substitute for tests of
>  > `pop-up-frames' now?  That is, what to do about code that 
>  > has (if pop-up-frames ...)?  What is the replacement for such
>  > a test in Emacs 24?  Thx.
> 
> Please decide together with David Engster where to bring the current
> discussion of bug#8857 to and try to give it an appropriate title.

Sorry, I haven't followed that bug at all, and I have no idea what you're saying
here.

> I can't find the idiom (if pop-up-frames in the current trunk
> so I would first like to know why and how it is used.

How about looking at the Emacs sources before you made your changes? ;-)  If you
grep the Emacs 20, 21, 22, or 23 Lisp source code for `pop-up-frames' you will
see lots of hits, some of which are tests of its value.  For example (Emacs
23.3):

From help.el:
(cond ((or pop-up-frames...)...)

From pcvs-util.el
(let ((pop-up-windows (or pop-up-windows pop-up-frames))

From diary-lib.el
(let* ((pop-up-frames (or pop-up-frames ...

From rmailsum.el
(if (and (one-window-p) pop-up-windows (not pop-up-frames))

From sendmail.el
(if (and (or nil ; ??????
             ...
             (and pop-up-frames (one-window-p))...)

From inf-lisp.el
(let ((pop-up-frames
       ;; Be willing to use another frame
       ;; that already has the window in it.
       (or pop-up-frames
           (get-buffer-window inferior-lisp-buffer t))))


Anyway, I meant in user code - my code.  I'm not trying to update the Emacs
sources.

I use such tests in only a couple of places.  They are of course based on the
(original) meaning of `pop-up-frames': non-nil means `display-buffer' uses a
separate frame.  Nothing special.

So the question is how to test that user intention using the latest Emacs
design.  From my code:

;; If non-nil `pop-up-frames' then inhibit showing annotation.
(let ((bookmark-automatically-show-annotations
       (and bookmark-automatically-show-annotations
            (not pop-up-frames))))

;; Use separate frames instead of windows if `pop-up-frames'
;; is non-nil or if prefix arg is negative.
(cond (...)
      ((or pop-up-frames option)
       (while file-list (find-file-other-frame...

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

[Drew Adams]

> > BTW, can you tell me what is a reasonable substitute for tests of
> > `pop-up-frames' now?  That is, what to do about code that has (if
> > pop-up-frames ...)?  What is the replacement for such a 
> > test in Emacs 24?  Thx.
> 
> 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'.

Non-nil was designed to mean that `display-buffer' uses another frame.  From the
Emacs 20-23 doc string (and probably ever since the variable existed - probably
Emacs 18):

"Non-nil means `display-buffer' should make a separate frame."

Emacs 23 added a particular non-nil value, `graphic-only', but the simple
nil/non-nil test behavior is what I'm after and is what the Emacs source code
has used as well - it's generally graphic displays that my code is concerned
with wrt frames.

See my reply to Martin for examples, if that helps.

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

[martin rudalics]

 > How about looking at the Emacs sources before you made your changes? ;-)  If you
 > grep the Emacs 20, 21, 22, or 23 Lisp source code for `pop-up-frames' you will
 > see lots of hits, some of which are tests of its value.  For example (Emacs
 > 23.3):
 >
 >>From help.el:
 > (cond ((or pop-up-frames...)...)
 > ...

All these tests will be removed/replaced in due time because these
variables are obsolete now.

 > I use such tests in only a couple of places.  They are of course based on the
 > (original) meaning of `pop-up-frames': non-nil means `display-buffer' uses a
 > separate frame.

And that was incorrect already in Emacs 23.  The value 'graphic-only
should have been dealt with separately.

 > Nothing special.
 >
 > So the question is how to test that user intention using the latest Emacs
 > design.  From my code:
 >
 > ;; If non-nil `pop-up-frames' then inhibit showing annotation.
 > (let ((bookmark-automatically-show-annotations
 >        (and bookmark-automatically-show-annotations
 >             (not pop-up-frames))))
 >
 > ;; Use separate frames instead of windows if `pop-up-frames'
 > ;; is non-nil or if prefix arg is negative.
 > (cond (...)
 >       ((or pop-up-frames option)
 >        (while file-list (find-file-other-frame...

Code shouldn't try to guess the user's intentions in the first place:
The strategy, in increasing priority, is

- users express their intentions in `display-buffer-alist',

- the code can suggest a better solution by passing a second argument to
   the buffer display function,

- users can override the code by setting the override specifier in
   `display-buffer-alist'.

Code should only express suggestions in the sense that "displaying the
buffer in this or that way is best to my knowledge".  The user can
accept that suggestion or override it.  In most cases, however, code
should not suggest anything and leave the decision to the user.

Obviously, if your code is targeted only at users not customizing
`display-buffer-alist', you can test `pop-up-frames' as before, taking
care of the special values 'unset (which means the user doesn't bother)
and 'graphic-only.  One benefit of this is that if `pop-up-frames' is
nil, the user has explicitly delared that she doesn't want to pop up new
frames with your code.

martin

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

[Drew Adams]

>  >> I can't find the idiom (if pop-up-frames in the current trunk
>  >> so I would first like to know why and how it is used.
>  >
>  > How about looking at the Emacs sources before you made 
>  > your changes? ;-)

Re-reading that now, I see that it could be misinterpreted.  I meant that even
if you find no such tests in the current Emacs code (i.e., after your changes,
which would be understandable, since you have probably removed them), there are
such occurrences in the Emacs code prior to your changes - i.e. Emacs 23.3, and
even in a build from two weeks ago.

You said that you found no occurrences of (if pop-up-frames...) in the source
code.  My point is that there are plenty of occurrences of nil/non-nil tests of
`pop-up-frames' in the Emacs 23/22/21/20/... source code.  grep for
`pop-up-frames', not just for "(if pop-up-frames".

>  > If you grep the Emacs 20, 21, 22, or 23 Lisp source code for 
>  > `pop-up-frames' you will see lots of hits, some of which are
>  > tests of its value.  For example (Emacs 23.3):
>  > From help.el: (cond ((or pop-up-frames...)...)
> 
> All these tests will be removed/replaced in due time because these
> variables are obsolete now.

No doubt.  The question was about what to replace such tests with.

I would even expect (like to see) an entry in etc/NEWS that addresses this
specifically.  It is typical when some construct becomes unrecommended or
deprecated to provide specific info about just what to use in its stead.  What
is the recommended replacement for a nil/non-nil test of `pop-up-frames'?

>  > I use such tests in only a couple of places.  They are of 
>  > course based on the (original) meaning of `pop-up-frames':
>  > non-nil means `display-buffer' uses a separate frame.
> 
> And that was incorrect already in Emacs 23.  The value 'graphic-only
> should have been dealt with separately.

Not if the code in question involves only graphic displays.

In any case, that is irrelevant to my concern.  Think Emacs 22 (or 21 or 20 or
19 or 18), if you prefer.  My code in a couple of places, and the Emacs 22
source code in many places, effects a nil/non-nil test of `pop-up-frames'.  What
is the proper replacement for that, i.e., to get the same behavior?

>  > Nothing special.  So the question is how to test that user
>  > intention using the latest Emacs design.  From my code:
>  >
>  > ;; If non-nil `pop-up-frames' then inhibit showing annotation.
>  > (let ((bookmark-automatically-show-annotations
>  >        (and bookmark-automatically-show-annotations
>  >             (not pop-up-frames))))
>  >
>  > ;; Use separate frames instead of windows if `pop-up-frames'
>  > ;; is non-nil or if prefix arg is negative.
>  > (cond (...)
>  >       ((or pop-up-frames option)
>  >        (while file-list (find-file-other-frame...
> 
> Code shouldn't try to guess the user's intentions in the first place:

Huh?  What is that about?  `pop-up-frames' is a user option.  What's to guess
about it?

How about forgetting for a moment what you think code should and shouldn't do,
and just let us know what the replacement for a nil/non-nil test of
`pop-up-frames' is?

> The strategy, in increasing priority, is
> 
> - users express their intentions in `display-buffer-alist',

What is the Emacs 24 equivalent to the intention expressed by - and the behavior
realized by, a nil/non-nil `pop-up-frames' test prior to Emacs 24 (i.e. prior to
the introduction of your feature)?

Can you express that behavior in terms of `display-buffer-alist'?  If so,
presumably you can give us the test of the `display-buffer-alist' value to use
in place of the nil/non-nil test of the `pop-up-frames' value, that is, a test
that gives the same behavior.

That's all I'm asking for here: how to do, using your new constructs, what we
have always done before using `pop-up-frames'.

> - the code can suggest a better solution by passing a second 
>   argument to the buffer display function,
> 
> - users can override the code by setting the override specifier in
>   `display-buffer-alist'.

That's all too vague for me, I'm afraid.  What is the answer to the question?
How to reproduce (e.g. by testing `display-buffer-alist') the same behavior that
testing `pop-up-frames' as a nil/non-nil value gave before?

> Code should only express suggestions in the sense that "displaying the
> buffer in this or that way is best to my knowledge".  The user can
> accept that suggestion or override it.  In most cases, however, code
> should not suggest anything and leave the decision to the user.

Please stop with the "should"s regarding programming style etc. - that's not
very helpful.  Emacs code has always bound some user variables.  There is
nothing special or sacrosanct about `pop-up-frames' in this regard.  Take a look
at the many bindings of `case-fold-search'...

In general, user settings "should" prevail, but there are cases where it can
make sense for code to override the user's preferred default behavior
(customization), including by binding a user option.  Whether or not a _given_
binding is appropriate is another matter.  But the blanket idea that code
"should not" bind user options is a non-starter, at least for me.

We can certainly agree to disagree about this.

But I will suggest that your point of view on it seems quite rigid, and it is
unsupported by historical experience - within either the Emacs sources or
third-party code.  Recognize that no one is saying that your code "should" bind
any given option.  It is you who is apparently declaring that _all_ code must
_never_ bind _any_ user option.  That is a quite rigid/doctrinaire view, no?

> Obviously, if your code is targeted only at users not customizing
> `display-buffer-alist', you can test `pop-up-frames' as before,

I'm perfectly willing and wanting to have my code support whatever is the new
design.  That's why I'm asking the question!

It does not matter in the end whether I think the new design is better or worse
than before, or better or worse than some possible alternative, or even whether
I understand it.  In any case, I want/need to support it in my code.  I'm not
redesigning Emacs here - you are.  I'm just trying to adapt my code to your
changes.

What I'm asking is how to do so.  My code needs to support multiple Emacs
versions, and I would like it to DTRT for Emacs 24, which I gather means testing
`display-buffer-alist' appropriately.  The question is how to use/test that
variable to get the same behavior as before, i.e., the same behavior as for
other Emacs versions.  Why is this such a hard question for you to address?

> taking care of the special values 'unset (which means the user 
> doesn't bother) and 'graphic-only.

Please tell me specifically what you mean - I don't follow.  Please take a given
nil/non-nil test of `pop-up-frames' and let me know what it would be for Emacs
24 and `display-buffer-alist' instead.

Preferably, translate Emacs 22's (if pop-up-frames...) to code that will do the
same thing in _both_ Emacs 22 and Emacs 24 - e.g., using `display-buffer-alist'
for the latter (i.e., when `boundp').  Thx.

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

[Stefan Monnier]

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

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

Do you have some example to point to, so we can try and see what new
predicate to define to provided the needed info?


        Stefan

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

[Drew Adams]

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

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

[martin rudalics]

 > I would even expect (like to see) an entry in etc/NEWS that addresses this
 > specifically.  It is typical when some construct becomes unrecommended or
 > deprecated to provide specific info about just what to use in its stead.

The NEWS entries and the manuals will be updated next week, hopefully.

 > What
 > is the recommended replacement for a nil/non-nil test of `pop-up-frames'?

Remove it.  Such a test is not reliable.

 > In any case, that is irrelevant to my concern.  Think Emacs 22 (or 21 or 20 or
 > 19 or 18), if you prefer.  My code in a couple of places, and the Emacs 22
 > source code in many places, effects a nil/non-nil test of `pop-up-frames'.  What
 > is the proper replacement for that, i.e., to get the same behavior?
 >
 >>  > Nothing special.  So the question is how to test that user
 >>  > intention using the latest Emacs design.  From my code:
 >>  >
 >>  > ;; If non-nil `pop-up-frames' then inhibit showing annotation.
 >>  > (let ((bookmark-automatically-show-annotations
 >>  >        (and bookmark-automatically-show-annotations
 >>  >             (not pop-up-frames))))
 >>  >
 >>  > ;; Use separate frames instead of windows if `pop-up-frames'
 >>  > ;; is non-nil or if prefix arg is negative.
 >>  > (cond (...)
 >>  >       ((or pop-up-frames option)
 >>  >        (while file-list (find-file-other-frame...
 >>
 >> Code shouldn't try to guess the user's intentions in the first place:
 >
 > Huh?  What is that about?  `pop-up-frames' is a user option.  What's to guess
 > about it?

Where the user wants to display the buffer.  With Emacs 23 you would in
general have to check for (1) display-buffer-function, (2) whether the
selected window shows the buffer already and can be used, and (3)
same-window-p, before you can safely decide that the user really wants
to pop up a new frame.

What you want to do is the same thing help functions tried before I
wrote the `with-help-window' macro.  Earlier, help tried to guess from
the settings of user options where `with-output-to-temp-buffer' would
put the buffer.  And the guesses were so often wrong that users
(including you) complained continuously.  So what's good for the
functions you peruse should be good for the functions you write.

With Emacs 24 a user can specify that the buffer should go into a new
window on the selected frame if a window of the desired height can be
created and in a new frame otherwise.  Which means that the user always
gets a window of the desired size.  You can't check whether the user
wants a new frame by looking at `display-buffer-alist' alone.  You have
to look at the sizes of the windows of the selected frame before you can
decide that the user really wants to create a new frame.

 > How about forgetting for a moment what you think code should and shouldn't do,
 > and just let us know what the replacement for a nil/non-nil test of
 > `pop-up-frames' is?

You first have to normalize specifiers as with
`display-buffer-normalize-specifiers'.  If in the resulting list, you
find an entry whose car is 'pop-up-frame you know that popping up a new
frame is one possible option.  Whether it will be tried depends on the
entries preceding it and the actual window configuration.

 > What is the Emacs 24 equivalent to the intention expressed by - and the behavior
 > realized by, a nil/non-nil `pop-up-frames' test prior to Emacs 24 (i.e. prior to
 > the introduction of your feature)?
 >
 > Can you express that behavior in terms of `display-buffer-alist'?  If so,
 > presumably you can give us the test of the `display-buffer-alist' value to use
 > in place of the nil/non-nil test of the `pop-up-frames' value, that is, a test
 > that gives the same behavior.
 >
 > That's all I'm asking for here: how to do, using your new constructs, what we
 > have always done before using `pop-up-frames'.

I added a new specifier to `display-buffer-alist' called
other-window-means-other-frame.  When a user sets this it means that the
user wants `display-buffer' called with the second argument t (and most
other scalar non-nil values) to pop up a new frame instead of a new
window.  I also added a function called
`display-buffer-other-window-means-other-frame' which tells you whether
a user has set that specifier for the buffer in question.  So when this
function returns a non-nil value you can safely assume that the user "in
principle" accepts popping up a new frame.  The function is included in
the code I sent you separately.

 > That's all too vague for me, I'm afraid.  What is the answer to the question?
 > How to reproduce (e.g. by testing `display-buffer-alist') the same behavior that
 > testing `pop-up-frames' as a nil/non-nil value gave before?

With `display-buffer-alist' the user sets up a list of options that
shall be tried by `display-buffer' until one succeeds.  There's no
equivalent to this in the old code where that order was hardcoded in
`display-buffer'.

 > Please stop with the "should"s regarding programming style etc. - that's not
 > very helpful.

I received complaints that applications impose a certain method for
displaying a buffer and the users didn't have a chance to change that.
Why can't we finally let _the user_ decide what `display-buffer' should
do?

 > Emacs code has always bound some user variables.  There is
 > nothing special or sacrosanct about `pop-up-frames' in this regard.  Take a look
 > at the many bindings of `case-fold-search'...
 >
 > In general, user settings "should" prevail, but there are cases where it can
 > make sense for code to override the user's preferred default behavior
 > (customization), including by binding a user option.  Whether or not a _given_
 > binding is appropriate is another matter.  But the blanket idea that code
 > "should not" bind user options is a non-starter, at least for me.
 >
 > We can certainly agree to disagree about this.

We disagree.

 > But I will suggest that your point of view on it seems quite rigid, and it is
 > unsupported by historical experience - within either the Emacs sources or
 > third-party code.  Recognize that no one is saying that your code "should" bind
 > any given option.  It is you who is apparently declaring that _all_ code must
 > _never_ bind _any_ user option.  That is a quite rigid/doctrinaire view, no?

I think code is better off if it respects the user.

 >> Obviously, if your code is targeted only at users not customizing
 >> `display-buffer-alist', you can test `pop-up-frames' as before,
 >
 > I'm perfectly willing and wanting to have my code support whatever is the new
 > design.  That's why I'm asking the question!

But then you should simply set the second argument of `display-buffer'
appropriately _without_ thinking of the user but only thinking of what's
best for the application.  If the user doesn't want what you propose
here she can override it.

 > It does not matter in the end whether I think the new design is better or worse
 > than before, or better or worse than some possible alternative, or even whether
 > I understand it.  In any case, I want/need to support it in my code.  I'm not
 > redesigning Emacs here - you are.  I'm just trying to adapt my code to your
 > changes.
 >
 > What I'm asking is how to do so.  My code needs to support multiple Emacs
 > versions, and I would like it to DTRT for Emacs 24, which I gather means testing
 > `display-buffer-alist' appropriately.  The question is how to use/test that
 > variable to get the same behavior as before, i.e., the same behavior as for
 > other Emacs versions.  Why is this such a hard question for you to address?

Your code didn't DTRT for Emacs 23.

 >> taking care of the special values 'unset (which means the user
 >> doesn't bother) and 'graphic-only.
 >
 > Please tell me specifically what you mean - I don't follow.  Please take a given
 > nil/non-nil test of `pop-up-frames' and let me know what it would be for Emacs
 > 24 and `display-buffer-alist' instead.
 >
 > Preferably, translate Emacs 22's (if pop-up-frames...) to code that will do the
 > same thing in _both_ Emacs 22 and Emacs 24 - e.g., using `display-buffer-alist'
 > for the latter (i.e., when `boundp').  Thx.

Sigh.  Maybe the new code does what you want.

martin

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

[Stefan Monnier]

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

If that's all you want to do, then "(if pop-up-frames" is (trivially)
the only answer.

But I'm pretty sure that's not the answer you're looking for because I'm
pretty sure that "test if pop-up-frames is non-nil" was *not* the
intention behind the code.  Now, it might be true that the coder doesn't
know his own intention.  It's a common problem.


        Stefan

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

[Drew Adams]

> The NEWS entries and the manuals will be updated next week, hopefully.
> 
>  > What is the recommended replacement for a nil/non-nil test of 
>  > `pop-up-frames'?
> 
> Remove it.  Such a test is not reliable.

That doesn't help.  What is the _replacement_?  In Emacs ...20,21,22,23, code
can test `pop-up-frames'.  What is the corresponding test using
`display-buffer-alist' (or whatever)?  If there is no exact correspondence then
what is the closest correspondence.

>  >> Code shouldn't try to guess the user's intentions in the 
>  >> first place:
>  >
>  > Huh?  What is that about?  `pop-up-frames' is a user option.
>  > What's to guess about it?
> 
> Where the user wants to display the buffer.  With Emacs 23 
> you would in general have to check for
> (1) display-buffer-function, (2) whether the
> selected window shows the buffer already and can be used, and (3)
> same-window-p, before you can safely decide that the user really wants
> to pop up a new frame.

What can I say?  The test of `pop-up-frames' tells me what I need to know in
Emacs 20,21,22,23, so that my code DTRT.  What is an equivalent test that I can
use in Emacs 24, so my code still DTRT?  That's all I'm asking.

If there is no exact equivalent, then let me know the closest thing.  I will try
it and see whether it is sufficient for my needs.

I'm asking to use your new features to get the same or very similar behavior -
nothing more.  Previously I could test the user's setting of `pop-up-frames' (at
least its current value) to determine what to do based on what the user wants
(at least as reflected in the current value).  How to do that now?

What's the closest mapping of `pop-up-frames' to (some part of)
`display-buffer-alist' or whatever the substitute is?

> You can't check whether the user wants a new frame by looking
> at `display-buffer-alist' alone.

Well, please give me the variables to check then.  And how to check them.

> You have to look at the sizes of the windows of the selected
> frame before you can decide that the user really wants to
> create a new frame.

Are you joking?  And just what must you look for?  And how do you decide based
on what you find?

Before, a user could specify that they generally wanted a separate frame (new or
existing, but separate), by just using non-nil `pop-up-frames'.  And code could
check that value and DTRT.

Now, you seem to be saying, code has to analyze a set of windows to determine
whether the user wants a separate frame?

Just how is that analysis done?  Please give us a code template that comes close
to the general case handled so simply before by just testing `pop-up-frames'.

What is the closest thing to the simple scenario we had before, of (1) a user
setting `pop-up-frames' to `t' to express wanting `display-buffer' to generally
use a separate frame and (2) code testing `pop-up-frames' to generally DTRT and
respect that user setting?

>  > just let us know what the replacement for a nil/non-nil test of
>  > `pop-up-frames' is
> 
> You first have to normalize specifiers as with
> `display-buffer-normalize-specifiers'.  If in the resulting list, you
> find an entry whose car is 'pop-up-frame you know that 
> popping up a new
> frame is one possible option.  Whether it will be tried depends on the
> entries preceding it and the actual window configuration.

Can you be please more specific?  Give an example, replacing a simple (if
pop-up-frames X Y) with recommended analysis-or-whatever code.

Please don't just send us off to read umpteen pages of code and explanation.
Let us start with a simple replacement example and see if that works well
enough.  If not, then we can dig deeper and try to understand more of your bells
and whistles.  Doing this will also help understanding.

>  > What is the Emacs 24 equivalent to the intention expressed 
>  > by - and the behavior realized by, a nil/non-nil
>  > `pop-up-frames' test prior to Emacs 24 (i.e. prior to
>  > the introduction of your feature)?
>  >
>  > Can you express that behavior in terms of 
>  > `display-buffer-alist'?  If so, presumably you can give us
>  > the test of the `display-buffer-alist' value to use
>  > in place of the nil/non-nil test of the `pop-up-frames' 
>  > value, that is, a test that gives the same behavior.
>  >
>  > That's all I'm asking for here: how to do, using your new 
>  > constructs, what we have always done before using `pop-up-frames'.
> 
> I added a new specifier to `display-buffer-alist' called
> other-window-means-other-frame.  When a user sets this it 
> means that the user wants `display-buffer' called with the second
> argument t (and most other scalar non-nil values) to pop up a new
> frame instead of a new window.  I also added a function called
> `display-buffer-other-window-means-other-frame' which tells 
> you whether a user has set that specifier for the buffer in
> question.  So when this function returns a non-nil value you can
> safely assume that the user "in principle" accepts popping up a
> new frame.  The function is included in the code I sent you
> separately.

I hate to say it, but OK, I figured I'd try to guess what you mean here, so I
took a look at `display-buffer-alist' (in the code you sent me) - and I'm lost.

I expected I'd see `other-window-means-other-frame' somewhere, but its only
presence was in the most complex defcustom :type expression I have ever seen.

So, I said to myself, OK, I'll try `M-x customize-option' - maybe things will be
clearer once I'm in Customize.  Whoa!  The Customize buffer from hell!

Sorry to kid a bit, but I cannot make hide nor hair of this.  Can you please
give me an example, showing what I can try changing `(if pop-up-frames X Y)' to,
to at least test this case you're developing of a user setting (something in)
`display-buffer-alist' to `other-window-means-other-frame'?

I'm guessing that even after I understand that, it won't be sufficient - that at
least some users who might have had non-nil `pop-up-frames' in Emacs prior to 24
will change to something slightly different for `display-buffer-alist' from just
using `other-window-means-other-frame'.  But let me at least start with handling
that case.  Please let me know how to test this.

Please understand that this all seems super-complex to me, so far.  The
complexity you've added for handling windows has little bearing for me as a user
because I don't often use more than one window per frame.  I'm not typical in
that, but that might be the case of at least some other users who have used
non-nil `pop-up-frames'.  When such a user (I'll try to speak for myself) sees
that Customize buffer s?he is overwhelmed.

Even just as a user I don't know how to customize the option to get a behavior
that is as close as possible to what I had before (`display-buffer' generally
using a separate frame).  As a programmer I have even less idea how to handle
different user settings that all might trace their ancestry to use of non-nil
`pop-up-frames' in prior releases.

I'm asking for a little help here.  I think other users and programmers could
probably use some guidance also.

I find it hard to believe that things really need to be so complex, as shown by
that Customize buffer.  But I do not pretend to be an expert on Emacs windowing,
and certainly not on using multiple windows per frame.

> With `display-buffer-alist' the user sets up a list of options that
> shall be tried by `display-buffer' until one succeeds.  There's no
> equivalent to this in the old code where that order was hardcoded in
> `display-buffer'.

That's fine.  I have no problem with that idea.  My problem is to know how to
deal with it, both as a user and a programmer.

To start with, how do I as a user customize `display-buffer-alist' to get a
behavior as close as possible to what I had in Emacs 22 or 23 by just setting
`pop-up-frames' to nil?

Do I remove all of the default `Display specifiers' and then add one that
corresponds to what I want?  If so, which one?

>  >> Obviously, if your code is targeted only at users not customizing
>  >> `display-buffer-alist', you can test `pop-up-frames' as before,
>  >
>  > I'm perfectly willing and wanting to have my code support 
>  > whatever is the new design.  That's why I'm asking the question!
> 
> But then you should simply set the second argument of `display-buffer'
> appropriately _without_ thinking of the user but only thinking of what's
> best for the application.  If the user doesn't want what you propose
> here she can override it.

Huh?  What _are_ you talking about?  I'm not even calling `display-buffer'
directly.  This is about code that tests `pop-up-frames', in order to respect
what the user has specified for that option.

You said that if my code doesn't target users who customize `d-b-a' then it can
test `p-u-f' as before.  I answered that I _want_ my code to target users who
now customize `d-b-a', since users will do just that from now on.

I have been asking, with no success so far, _how_ to do that.  What is the
equivalent, or a close equivalent, for testing `d-b-a' now to testing
`pop-up-frames' in the past?

>  > I'm just trying to adapt my code to your changes.
>  >
>  > What I'm asking is how to do so.  My code needs to support 
>  > multiple Emacs versions, and I would like it to DTRT for Emacs
>  > 24, which I gather means testing `display-buffer-alist'
>  > appropriately.
>  >
>  > The question is how to use/test that
>  > variable to get the same behavior as before, i.e., the 
>  > same behavior as for other Emacs versions.
>  >
>  > Why is this such a hard question for you to address?
> 
> Your code didn't DTRT for Emacs 23.

How the f do you know that?  It works well enough for me and those who use it,
which is what it was designed for.

All I'm asking you is how to use your new features, to do what we've done before
using `pop-up-frames' - since you are replacing/deprecating that option.  You
have talked all around the question to no end, but you haven't answered it.

There are tests of `pop-up-frames' in the Emacs source code.  How will you
replace them?  That info would provide an example as a starting point, at least.

>  > Please tell me specifically what you mean - I don't 
>  > follow.  Please take a given nil/non-nil test of
>  > `pop-up-frames' and let me know what it would be for
>  > Emacs 24 and `display-buffer-alist' instead.
>  >
>  > Preferably, translate Emacs 22's (if pop-up-frames...) to 
>  > code that will do the same thing in _both_ Emacs 22 and
>  > Emacs 24 - e.g., using `display-buffer-alist'
>  > for the latter (i.e., when `boundp').  Thx.
> 
> Sigh.

Why "sigh"?  Why is that so hard?  You get rid of (deprecate) X, saying to use Y
instead, but you won't give an example of _how_ to use Y instead of X?

> Maybe the new code does what you want.

Do you mean the new version of window.el you sent me?  Sadly, no - the same
symptoms are there as I described originally.

But my previous test with your suggested `display-buffer-normalize-specifiers-1'
worked, as I mentioned.  You said you would install that, but it differs from
the definition that is in the window.el version you sent me.

And in fact I cannot even use the two together: If I load the window.el you sent
me and then eval the `display-buffer-normalize-specifiers-1' version you posted
in this thread (which worked, by itself), then I get this error:

Entering debugger...
let*: Wrong number of arguments: (lambda (specifiers) "Subroutine of
`display-buffer-normalize-specifiers'.
SPECIFIERS is the SPECIFIERS argument of `display-buffer'." (let (normalized
entry) (cond ((not specifiers) nil) ((listp specifiers) (dolist (specifier
specifiers) (cond ((consp specifier) (setq normalized (cons specifier
normalized))) ((symbolp specifier) (let ((entry ...)) (dolist (item ...) (setq
normalized ...)))))) (nreverse normalized)) ((and (not (eq specifiers (quote
other-window))) (setq entry (assq specifiers display-buffer-macro-specifiers)))
(cdr entry)) ((memq pop-up-frames (quote (nil unset))) (cdr (assq (quote
other-window) display-buffer-macro-specifiers))) (t (cdr (assq (quote
other-frame) display-buffer-macro-specifiers)))))), 3

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

[Drew Adams]

> > 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.
> 
> If that's all you want to do, then "(if pop-up-frames" is (trivially)
> the only answer.

Well, yes, in Emacs 20-23.  But if `pop-up-frames' is being deprecated then what
is the _replacement_ for such a test, going forward?

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

[Stefan Monnier]

>> > 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.
>> If that's all you want to do, then "(if pop-up-frames" is (trivially)
>> the only answer.

> Well, yes, in Emacs 20-23.  But if `pop-up-frames' is being deprecated
> then what is the _replacement_ for such a test, going forward?

If your point is to test pop-up-frames, then by all means do that.
And if it disappears, then change your code so it doesn't signal
an error.
As long as you don't give me the intention behind the check, there is no
better answer.


        Stefan

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

[Drew Adams]

> >> > 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.
> >> If that's all you want to do, then "(if pop-up-frames" is 
> >> (trivially) the only answer.
> 
> > Well, yes, in Emacs 20-23.  But if `pop-up-frames' is being 
> > deprecated then what is the _replacement_ for such a test,
> > going forward?
> 
> If your point is to test pop-up-frames, then by all means do that.

No, why do you keep saying that?

My point _in Emacs 20-23_ was to test `pop-up-frames'.  I'm looking to do for
Emacs 24+ whatever is appropriate, to get the same or very similar behavior.

My point is _not_ to test `pop-up-frames' in Emacs 24+, but to test whatever is
now recommended instead of `pop-up-frames', in order to get the same/similar
behavior as before.

Don't you have the same problem in the Emacs sources?  There are plenty of tests
of `pop-up-frames' there.  How will you be replacing them?

I have only two such tests in my code.  I'm trying to learn what to do in their
stead.  You say in effect "don't test `pop-up-frames' anymore", and my question
is OK, what do I test instead to get the same effect?

> And if it disappears, then change your code so it doesn't signal
> an error.  As long as you don't give me the intention behind the
> check, there is no better answer.

The intention (in Emacs < 24) was to key the code's behavior off of
`pop-up-frames' as specified by the user, in order to DTRT based on the
intention about `display-buffer' and separate frames that the user communicated
via `pop-up-frames'.

For Emacs 24+ the intention is to key the behavior off of the new variable that
replaces `pop-up-frames', whatever it is.  I realize that there is no simple
variable that corresponds to `pop-up-frames'.  I'm asking about whatever is
equivalent (as much as possible) and can be similarly tested - presumably some
part of `display-buffer-alist'.  What is an equivalent test, for `d-b-a'?

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

[Stefan Monnier]

> My point _in Emacs 20-23_ was to test `pop-up-frames'.

And I'm telling you that you're wrong.


        Stefan

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

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

FYI - This bug is fixed by the second version of window that you sent me today,
Martin.

To see that it is fixed, load the attached file after emacs -Q, then do this
(same recipe as originally):

M-x find-library-other-window RET frame.el RET

Buffer frame.el is now shown in a separate frame, not just a separate window as
before your latest window.el.

(P.S. The attached file assumes your latest window.el is in the current
directory and named "window-2011-06-19a-MARTIN.el".)

[-- Attachment #2: throw-8865.el --]
[-- Type: application/octet-stream, Size: 958 bytes --]

; emacs -Q

(setq pop-up-frames t)
(require 'find-func)
(load-file "window-2011-06-19a-MARTIN.el")

(defun find-library-other-window (library)
  "Find the Emacs-Lisp source of LIBRARY in another window."
  (interactive
   (let* ((path (cons (or find-function-source-path load-path)
        (find-library-suffixes)))
   (def (if (eq (function-called-at-point) 'require)
     (save-excursion (backward-up-list)
                                   (forward-char)
                                   (backward-sexp -2)
                                   (thing-at-point 'symbol))
   (thing-at-point 'symbol))))
     (when def (setq def (and (locate-file-completion def path 'test) def)))
     (list (completing-read "Library name: " 'locate-file-completion
                            path nil nil nil def))))
  (let ((buf (find-file-noselect (find-library-name library))))
    (pop-to-buffer buf 'other-window)))

; M-x find-library-other-window RET frame.el RET

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

[martin rudalics]

> FYI - This bug is fixed by the second version of window that you sent me today,
[...]
> (P.S. The attached file assumes your latest window.el is in the current
> directory and named "window-2011-06-19a-MARTIN.el".)

This bug was already fixed (and closed) a couple of days ago ;-)

martin

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

[Drew Adams]

However, I would still appreciate some guidance wrt replacing current (pre Emacs
24) tests of `pop-up-frames' and, more generally, the use of
`display-buffer-alist' (both as a user and wrt code that would test its value).

IOW, there are open questions about `display-buffer-alist' raised in this bug
thread.

Even as some of these bugs introduced by your changes get fixed, so that the new
Emacs code becomes more correctly backward-compatible wrt `pop-up-frames', the
goal is to move away from `pop-up-frames'.  So that is where more guidance would
be helpful, for both users and elisp programmers.