bug#67249: 30.0.50; `same-frame` equivalent for `display-buffer-alist`

[Stefan Monnier]

> pop-up-frames described here is a user option, so saying "the value of
> this parameter" is wrong.  My suggestion is to leave the current text
> alone, and add after it something like
>
>   An entry by the same name in @code{display-buffer}'s @var{alist}
>   takes precedence over the variable.

Thanks.  The doc change is now as below.


        Stefan


diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi
index 22c1b307252..5f5e5d143aa 100644
--- a/doc/lispref/windows.texi
+++ b/doc/lispref/windows.texi
@@ -3268,6 +3268,15 @@ Buffer Display Action Alists
 if one is created.  @code{display-buffer-pop-up-frame} is its one and
 only addressee.
 
+@vindex pop-up-frames{, a buffer display action alist entry}
+@item pop-up-frames
+This value controls whether @code{display-buffer} may display buffers
+by making new frames.  It has the same meaning as the
+@code{pop-up-frames} variable and takes precedence over it when present.
+Its main intended purpose is to override a non-nil value of the
+variable for particular buffers which the user prefers to keep
+in the selected frame.
+
 @vindex parent-frame@r{, a buffer display action alist entry}
 @item parent-frame
 The value specifies the parent frame to be used when the buffer is
@@ -3441,6 +3450,9 @@ Choosing Window Options
 looking for a window already displaying @var{buffer-or-name}, it can
 search any visible or iconified frame, not just the selected frame.
 
+An entry by the same name in @code{display-buffer}'s @var{alist}
+takes precedence over the variable.
+
 This variable is provided mainly for backward compatibility.  It is
 obeyed by @code{display-buffer} via a special mechanism in
 @code{display-buffer-fallback-action}, which calls the action function