bug#37840: Missing in the Emacs manuals:

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

There is no detailed example in the emacs manuals on how to migrate from using "special-display-frame-alist" and "special-display-regexps" to "display-buffer-alist."

E.g., how to migrate from 

(setq special-display-frame-alist
   (quote
    ((height . 42)
    (width . 83)
    (left . 770)
    (unsplittable)
    (tool-bar-lines . 0)
    (left-fringe . 0)
    (right-fringe . 0)
    (line-spacing . 0)
    (font . "Monaco-12")
    (top . 110))))

 and

(setq special-display-regexps '((".*output*" (right-fringe . 0) (left-fringe . 0) (top . 330) (left . 152)
  (width . 86) (height . 32)
  (tool-bar-lines . 0) (font . "Menlo-10") (menu-bar-lines . 0) "[ ]?[*][^*]+[*]"))

?

Konrad

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > There is no detailed example in the emacs manuals on how to migrate
 > from using "special-display-frame-alist" and
 > "special-display-regexps" to "display-buffer-alist."

I'm not sure whether I'll be able to come up with something reasonable
in this regard, mainly because I've never been able to understand the
special display function mechanism.

 > E.g., how to migrate from
 >
 > (setq special-display-frame-alist
 >     (quote
 >      ((height . 42)
 >      (width . 83)
 >      (left . 770)
 >      (unsplittable)
 >      (tool-bar-lines . 0)
 >      (left-fringe . 0)
 >      (right-fringe . 0)
 >      (line-spacing . 0)
 >      (font . "Monaco-12")
 >      (top . 110))))
 >
 >   and
 >
 > (setq special-display-regexps '((".*output*" (right-fringe . 0) (left-fringe . 0) (top . 330) (left . 152)
 >    (width . 86) (height . 32)
 >    (tool-bar-lines . 0) (font . "Menlo-10") (menu-bar-lines . 0)))

You can try the following untested snippet (your regxp looks a bit
odd, BTW):

(setq my-special-display-frame-alist
       (quote
        ((height . 42)
	(width . 83)
	(left . 770)
	(unsplittable)
	(tool-bar-lines . 0)
	(left-fringe . 0)
	(right-fringe . 0)
	(line-spacing . 0)
	(font . "Monaco-12")
	(top . 110))))

(setq my-special-display-regexps
       '((".*output*"
	 (right-fringe . 0)
	 (left-fringe . 0)
	 (top . 330)
	 (left . 152)
	 (width . 86)
	 (height . 32)
	 (tool-bar-lines . 0)
	 (font . "Menlo-10")
	 (menu-bar-lines . 0))))

(setq display-buffer-alist
       `((".*output*"
	 (display-buffer-reuse-window
	  ; display-buffer-same-window
	  ; display-buffer-pop-up-window
	  display-buffer-pop-up-frame)
	 (reusable-frames . 0) (inhibit-switch-frame . nil)
	 (pop-up-frame-parameters . ,(append (cdr my-special-display-regexps)
					       special-display-frame-alist)))))

where you have to comment-in the respective alist functions when you
use 'same-window' or 'same-frame' in your 'special-display-regexps'
settings (apparently you don't).

I can put a similar example into the Elisp manual (Eli would have to
figure out the details to omit or add) but note the following two not
entirely negligible differences:

'special-display-popup-frame' (the default for
'special-display-function') uses

        (when (cdr (assq 'same-window args))
	 (condition-case nil
	     (progn (switch-to-buffer buffer nil t) (selected-window))
	   (error nil)))

which has no direct equivalent in the 'display-buffer-alist'
ecosystem.  I used 'display-buffer-same-window' instead but that does
not obey options like 'switch-to-buffer-in-dedicated-window' or
'switch-to-buffer-preserve-window-point'.  Which means that for a
faithful migration you would have to write your own action function
here.

The second difference derives from the fact that
'special-display-popup-frame' marks the window on a new frame as
dedicated to its buffer.  This is no more needed in the
'display-buffer-alist' world because there the 'quit-restore' window
parameter takes care of the problem the former tries to solve.  Still
this means a behavioral difference that should be mentioned.  I
_cannot_ add a non-nil 'dedicated' alist entry because that would be
applied by any other action function ('display-buffer-pop-up-window'
foremost) too.

Also I have left out details like the function to be called when the
car of the ARGS argument of 'special-display-popup-frame' is a symbol
or how to treat 'special-display-buffer-names' ...

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

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

Thanks for your reply. Working on the stuff, I encountered the following problem: If, in “ display-buffer-alist”, I have the entry:

      ("[ ]?Packages[ ]?" (display-buffer-reuse-window display-buffer-pop-up-frame)
       (pop-up-frame-parameters
        (tool-bar-lines . 1)
	(left . 1)
	(left-fringe . 2)
        (top . 0)
	(height . 65)
	(width . 149)
	(font . "SF MONO-18")
        (line-spacing . 3)
	))

then, contrary to what is promised, this does not pop up a new frame. I figured out that the problem goes away if, in “packages.el”, I replace in the defun “list-packages” the  code (switch-to-buffer buf) by (pop-to-buffer buf). My question is how to do this on the level of customizing “display-buffer-alist”. I didn’t find anything in this regard in the manuals.




> Am 22.10.2019 um 10:43 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > There is no detailed example in the emacs manuals on how to migrate
> > from using "special-display-frame-alist" and
> > "special-display-regexps" to "display-buffer-alist."
> 
> I'm not sure whether I'll be able to come up with something reasonable
> in this regard, mainly because I've never been able to understand the
> special display function mechanism.
> 
> > E.g., how to migrate from
> >
> > (setq special-display-frame-alist
> >     (quote
> >      ((height . 42)
> >      (width . 83)
> >      (left . 770)
> >      (unsplittable)
> >      (tool-bar-lines . 0)
> >      (left-fringe . 0)
> >      (right-fringe . 0)
> >      (line-spacing . 0)
> >      (font . "Monaco-12")
> >      (top . 110))))
> >
> >   and
> >
> > (setq special-display-regexps '((".*output*" (right-fringe . 0) (left-fringe . 0) (top . 330) (left . 152)
> >    (width . 86) (height . 32)
> >    (tool-bar-lines . 0) (font . "Menlo-10") (menu-bar-lines . 0)))
> 
> You can try the following untested snippet (your regxp looks a bit
> odd, BTW):
> 
> (setq my-special-display-frame-alist
>      (quote
>       ((height . 42)
> 	(width . 83)
> 	(left . 770)
> 	(unsplittable)
> 	(tool-bar-lines . 0)
> 	(left-fringe . 0)
> 	(right-fringe . 0)
> 	(line-spacing . 0)
> 	(font . "Monaco-12")
> 	(top . 110))))
> 
> (setq my-special-display-regexps
>      '((".*output*"
> 	 (right-fringe . 0)
> 	 (left-fringe . 0)
> 	 (top . 330)
> 	 (left . 152)
> 	 (width . 86)
> 	 (height . 32)
> 	 (tool-bar-lines . 0)
> 	 (font . "Menlo-10")
> 	 (menu-bar-lines . 0))))
> 
> (setq display-buffer-alist
>      `((".*output*"
> 	 (display-buffer-reuse-window
> 	  ; display-buffer-same-window
> 	  ; display-buffer-pop-up-window
> 	  display-buffer-pop-up-frame)
> 	 (reusable-frames . 0) (inhibit-switch-frame . nil)
> 	 (pop-up-frame-parameters . ,(append (cdr my-special-display-regexps)
> 					       special-display-frame-alist)))))
> 
> where you have to comment-in the respective alist functions when you
> use 'same-window' or 'same-frame' in your 'special-display-regexps'
> settings (apparently you don't).
> 
> I can put a similar example into the Elisp manual (Eli would have to
> figure out the details to omit or add) but note the following two not
> entirely negligible differences:
> 
> 'special-display-popup-frame' (the default for
> 'special-display-function') uses
> 
>       (when (cdr (assq 'same-window args))
> 	 (condition-case nil
> 	     (progn (switch-to-buffer buffer nil t) (selected-window))
> 	   (error nil)))
> 
> which has no direct equivalent in the 'display-buffer-alist'
> ecosystem.  I used 'display-buffer-same-window' instead but that does
> not obey options like 'switch-to-buffer-in-dedicated-window' or
> 'switch-to-buffer-preserve-window-point'.  Which means that for a
> faithful migration you would have to write your own action function
> here.
> 
> The second difference derives from the fact that
> 'special-display-popup-frame' marks the window on a new frame as
> dedicated to its buffer.  This is no more needed in the
> 'display-buffer-alist' world because there the 'quit-restore' window
> parameter takes care of the problem the former tries to solve.  Still
> this means a behavioral difference that should be mentioned.  I
> _cannot_ add a non-nil 'dedicated' alist entry because that would be
> applied by any other action function ('display-buffer-pop-up-window'
> foremost) too.
> 
> Also I have left out details like the function to be called when the
> car of the ARGS argument of 'special-display-popup-frame' is a symbol
> or how to treat 'special-display-buffer-names' ...
> 
> martin


[-- Attachment #2: Type: text/html, Size: 88213 bytes --]

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > Thanks for your reply. Working on the stuff, I encountered the following problem: If, in “ display-buffer-alist”, I have the entry:
 >
 >        ("[ ]?Packages[ ]?" (display-buffer-reuse-window display-buffer-pop-up-frame)
 >         (pop-up-frame-parameters
 >          (tool-bar-lines . 1)
 > 	(left . 1)
 > 	(left-fringe . 2)
 >          (top . 0)
 > 	(height . 65)
 > 	(width . 149)
 > 	(font . "SF MONO-18")
 >          (line-spacing . 3)
 > 	))
 >
 > then, contrary to what is promised, this does not pop up a new
 > frame.

There's no promise that 'display-buffer-alist' controls the behavior
of 'switch-to-buffer'.  The latter should be used interactively (via
C-x b) only.  But since that's practically impossible given the sheer
mass of occurrences of 'switch-to-buffer' in the Emacs code base, Juri
added the 'switch-to-buffer-obey-display-actions' option.  If that is
non-nil, your use case should work.

 > I figured out that the problem goes away if, in
 > “packages.el”, I replace in the defun “list-packages” the code
 > (switch-to-buffer buf) by (pop-to-buffer buf). My question is how to
 > do this on the level of customizing “display-buffer-alist”. I didn’t
 > find anything in this regard in the manuals.

'switch-to-buffer' preferably shows its buffer in the same (selected)
window.  'pop-to-buffer' has no such preference.

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

Thanks for your reply. With the "switch-to-buffer-obey-display-actions" option, opening of files works according to "display-buffer-alist". However, now the following problem appears. E.g., I have 

      ("[ ]?mail[ ]?" (display-buffer-reuse-window display-buffer-pop-up-frame)
        (reusable-frames nil)
        (pop-up-frame-parameters
        (tool-bar-lines . 1)
	(left . 859)
	(left-fringe . 2)
        (top . 183)
	(height . 32)
	(width . (text-pixels . 837))
	(font . "SF MONO-18")
        (line-spacing . 3)
        ))


in "display-buffer-alist". Now if I have some buffer.foo open in its own frame, and then issue C-x m, a new message buffer pops up in its own frame, as it should be. However, after finally issuing C-c C-c to send the mail, the frame which contained the mail buffer does not disappear (as it was the case with the old special-display.regexp stuff), rather this frame shows a second instance of buffer.foo.

Thanks, 

Konrad





> Am 23.10.2019 um 09:46 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > Thanks for your reply. Working on the stuff, I encountered the following problem: If, in “ display-buffer-alist”, I have the entry:
> >
> >        ("[ ]?Packages[ ]?" (display-buffer-reuse-window display-buffer-pop-up-frame)
> >         (pop-up-frame-parameters
> >          (tool-bar-lines . 1)
> > 	(left . 1)
> > 	(left-fringe . 2)
> >          (top . 0)
> > 	(height . 65)
> > 	(width . 149)
> > 	(font . "SF MONO-18")
> >          (line-spacing . 3)
> > 	))
> >
> > then, contrary to what is promised, this does not pop up a new
> > frame.
> 
> There's no promise that 'display-buffer-alist' controls the behavior
> of 'switch-to-buffer'.  The latter should be used interactively (via
> C-x b) only.  But since that's practically impossible given the sheer
> mass of occurrences of 'switch-to-buffer' in the Emacs code base, Juri
> added the 'switch-to-buffer-obey-display-actions' option.  If that is
> non-nil, your use case should work.
> 
> > I figured out that the problem goes away if, in
> > “packages.el”, I replace in the defun “list-packages” the code
> > (switch-to-buffer buf) by (pop-to-buffer buf). My question is how to
> > do this on the level of customizing “display-buffer-alist”. I didn’t
> > find anything in this regard in the manuals.
> 
> 'switch-to-buffer' preferably shows its buffer in the same (selected)
> window.  'pop-to-buffer' has no such preference.
> 
> martin
> 

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > Now if I have some buffer.foo open in its own frame, and then issue
 > C-x m, a new message buffer pops up in its own frame, as it should
 > be. However, after finally issuing C-c C-c to send the mail, the
 > frame which contained the mail buffer does not disappear (as it was
 > the case with the old special-display.regexp stuff), rather this
 > frame shows a second instance of buffer.foo.

Can you tell me the function(s) called by C-c C-c to get rid of the
window or the mail buffer?  From what you say here, the function can
be hardly 'kill-buffer' because that would not show "a second instance
of buffer.foo".  And what is a second instance of a buffer?

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

C-c C-c in this case runs the function "message-send-and-exit” from message.el:

(defun message-send-and-exit (&optional arg)
  "Send message like `message-send', then, if no errors, exit from mail buffer.
The usage of ARG is defined by the instance that called Message.
It should typically alter the sending method in some way or other."
  (interactive "P")
  (let ((buf (current-buffer))
	(actions message-exit-actions))
    (when (and (message-send arg)
	       (buffer-name buf))
      (message-bury buf)
      (if message-kill-buffer-on-exit
	  (kill-buffer buf))
      (message-do-actions actions)
      t)))

By “second instance” I meant the following situation:

Suppose originally I had frame A with buffer.foo and frame B with buffer.mail,

then after C-c  C-c	I get

frame A with buffer.foo and frame with B buffer.foo


> Am 28.10.2019 um 19:13 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > Now if I have some buffer.foo open in its own frame, and then issue
> > C-x m, a new message buffer pops up in its own frame, as it should
> > be. However, after finally issuing C-c C-c to send the mail, the
> > frame which contained the mail buffer does not disappear (as it was
> > the case with the old special-display.regexp stuff), rather this
> > frame shows a second instance of buffer.foo.
> 
> Can you tell me the function(s) called by C-c C-c to get rid of the
> window or the mail buffer?  From what you say here, the function can
> be hardly 'kill-buffer' because that would not show "a second instance
> of buffer.foo".  And what is a second instance of a buffer?
> 
> martin

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 >        (message-bury buf)

'message-bury' calls 'bury-buffer' in a pretty contrived way instead
of simply calling 'quit-restore-window'.  But as long as I don't know
what it is really supposed to do, I can't change it.

In practice, this means that you have to include a 'dedicated' entry
like

       ("[ ]?mail[ ]?" (display-buffer-reuse-window display-buffer-pop-up-frame)
         (reusable-frames nil)
	(dedicated . t)
         (pop-up-frame-parameters
         (tool-bar-lines . 1)
	(left . 859)
	(left-fringe . 2)
         (top . 183)
	(height . 32)
	(width . (text-pixels . 837))
	(font . "SF MONO-18")
         (line-spacing . 3)
         ))

and I will add an according advice to the manual once your setup has
stabilized.

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

The entry (dedicated . t) did the job. (BTW, where is this possibility documented?)

Thanks,  

Konrad

> Am 29.10.2019 um 10:28 schrieb martin rudalics <rudalics@gmx.at>:
> 
> >        (message-bury buf)
> 
> 'message-bury' calls 'bury-buffer' in a pretty contrived way instead
> of simply calling 'quit-restore-window'.  But as long as I don't know
> what it is really supposed to do, I can't change it.
> 
> In practice, this means that you have to include a 'dedicated' entry
> like
> 
>      ("[ ]?mail[ ]?" (display-buffer-reuse-window display-buffer-pop-up-frame)
>        (reusable-frames nil)
> 	(dedicated . t)
>        (pop-up-frame-parameters
>        (tool-bar-lines . 1)
> 	(left . 859)
> 	(left-fringe . 2)
>        (top . 183)
> 	(height . 32)
> 	(width . (text-pixels . 837))
> 	(font . "SF MONO-18")
>        (line-spacing . 3)
>        ))
> 
> and I will add an according advice to the manual once your setup has
> stabilized.
> 
> martin

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > The entry (dedicated . t) did the job. (BTW, where is this possibility documented?)

In section 28.15 Dedicated Windows of the Elisp manual.  But as I said
in my first answer in this thread, indiscriminately applying a non-nil
'dedicated' entry is not generally advisable since it might affect
windows that pop up on the same frame too, with the consequence that
you can no longer switch buffers in such windows.  And it won't handle
the case where the buffer is shown in the selected window either.

As explained in section 28.16 Quitting Windows of the Elisp manual,
'quit-restore-window' could automatically DTRT for windows like that
used for composing mail, so there would be no need for a 'dedicated'
entry.  But 'message-send-and-exit' calls 'message-bury' and that uses
a slightly weird strategy to possibly get rid of the window with the
consequence that 'quit-restore-window' won't even get called here.

A zache Gschicht, so to say.

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

Thanks for your response. I have another question, on the following customization:


(setq display-buffer-base-action
       (quote (
  (display-buffer-reuse-window display-buffer-pop-up-frame)
  (reusable-frames . t)
 )))

(setq display-buffer-alist
       (quote (
      ("\\*[^s][^s]" (display-buffer-reuse-window display-buffer-pop-up-frame)
       (pop-up-frame-parameters
        (width . 92)
        (height . 48)
        (left . 1150)
        (unsplittable)
        (tool-bar-lines . 0)
        (left-fringe . 0)
        (right-fringe . 0)
        (line-spacing . 0)
        (font . "Monaco-12")
        (top . 180)
      ))
)))

Suppose I have buffer A open in frame A. Issuing occur->some word, the occur buffer pops up in its own frame, say frame B, as intended with the above customization. Moreover, frame B has input focus. Returning to frame A, without closing frame B, and issuing another time occur-> some word, frame B now shows the new occur buffer, as intended, but this time frame B lacks input focus. What goes wrong the second time?

Let me mention that if, in window.el, I add 

(x-focus-frame (window-frame window))

at the very end of the defun "display-buffer-reuse-window", the problem goes away, i.e., in the above example, frame B gets input focus after every invocation of occur in frame A. How can I get this with a suitable customization on the "display-buffer-alist" level?

Thanks

Konrad






 

> Am 30.10.2019 um 09:14 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > The entry (dedicated . t) did the job. (BTW, where is this possibility documented?)
> 
> In section 28.15 Dedicated Windows of the Elisp manual.  But as I said
> in my first answer in this thread, indiscriminately applying a non-nil
> 'dedicated' entry is not generally advisable since it might affect
> windows that pop up on the same frame too, with the consequence that
> you can no longer switch buffers in such windows.  And it won't handle
> the case where the buffer is shown in the selected window either.
> 
> As explained in section 28.16 Quitting Windows of the Elisp manual,
> 'quit-restore-window' could automatically DTRT for windows like that
> used for composing mail, so there would be no need for a 'dedicated'
> entry.  But 'message-send-and-exit' calls 'message-bury' and that uses
> a slightly weird strategy to possibly get rid of the window with the
> consequence that 'quit-restore-window' won't even get called here.
> 
> A zache Gschicht, so to say.
> 
> martin

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > Suppose I have buffer A open in frame A. Issuing occur->some word,
 > the occur buffer pops up in its own frame, say frame B, as intended
 > with the above customization. Moreover, frame B has input
 > focus. Returning to frame A, without closing frame B, and issuing
 > another time occur-> some word, frame B now shows the new occur
 > buffer, as intended, but this time frame B lacks input focus. What
 > goes wrong the second time?

Nothing, I suppose.  'occur' (I suppose that's the function you
invoke) calls 'occur-1' and that one simply does

             (display-buffer occur-buf)

which according to its doc-string does

   Display BUFFER-OR-NAME in some window, without selecting it.

IIUC the philosophy of 'occur' is given in its doc-string as

   The lines are shown in a buffer named `*Occur*'.
   It serves as a menu to find any of the occurrences in this buffer.

and programs usually don't preselect menus either.  The user has to
reach for the mouse or type some key to go there first ...

So the question is rather "what goes wrong the first time?".  The
answer to that is that, when 'display-buffer' creates a new frame, the
window manager usually also gives that new frame input focus.  Some
window managers allow to change that for all applications.  If you add
a non-nil 'no-focus-on-map' entry to your 'pop-up-frame-parameters',
Emacs will ask the window manager to not focus the new frame and
channces are that your window manager complies.

 > Let me mention that if, in window.el, I add
 >
 > (x-focus-frame (window-frame window))
 >
 > at the very end of the defun "display-buffer-reuse-window", the
 > problem goes away, i.e., in the above example, frame B gets input
 > focus after every invocation of occur in frame A. How can I get this
 > with a suitable customization on the "display-buffer-alist" level?

You can't.  I think the most simple way to achieve what you want is to
add a function to 'occur-hook' that does search for a window that
shows the current buffer and, if it finds such a window, invokes
'select-frame-set-input-focus' for that window's frame.

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

I don't find anything in the manual related to the following:


Suppose, without any display-buffer-alist customization, I have just

(setq display-buffer-base-action
       (quote (
  (display-buffer-reuse-window display-buffer-pop-up-frame)
  (reusable-frames . x)
)))

in my init file, where x can be any of  0,1, nil, visible, all these choices don’t matter for this: If I open Emacs, the initial frame shows up, and any file loaded via recent-files, or by dragging on the Emacs icon, or by clicking on the file icon, shows up in the initial frame, contrary to what is advertised in the manual. However, once a file is loaded, then re-selecting it via Menu->Buffers, pops it up in a new frame (with properties as specified in defaults-frame-alist). So, what is the relation between "display-buffer-base-action” and “default-frame-alist”?

Thanks,

Konrad


> Am 31.10.2019 um 08:59 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > Suppose I have buffer A open in frame A. Issuing occur->some word,
> > the occur buffer pops up in its own frame, say frame B, as intended
> > with the above customization. Moreover, frame B has input
> > focus. Returning to frame A, without closing frame B, and issuing
> > another time occur-> some word, frame B now shows the new occur
> > buffer, as intended, but this time frame B lacks input focus. What
> > goes wrong the second time?
> 
> Nothing, I suppose.  'occur' (I suppose that's the function you
> invoke) calls 'occur-1' and that one simply does
> 
>            (display-buffer occur-buf)
> 
> which according to its doc-string does
> 
>  Display BUFFER-OR-NAME in some window, without selecting it.
> 
> IIUC the philosophy of 'occur' is given in its doc-string as
> 
>  The lines are shown in a buffer named `*Occur*'.
>  It serves as a menu to find any of the occurrences in this buffer.
> 
> and programs usually don't preselect menus either.  The user has to
> reach for the mouse or type some key to go there first ...
> 
> So the question is rather "what goes wrong the first time?".  The
> answer to that is that, when 'display-buffer' creates a new frame, the
> window manager usually also gives that new frame input focus.  Some
> window managers allow to change that for all applications.  If you add
> a non-nil 'no-focus-on-map' entry to your 'pop-up-frame-parameters',
> Emacs will ask the window manager to not focus the new frame and
> channces are that your window manager complies.
> 
> > Let me mention that if, in window.el, I add
> >
> > (x-focus-frame (window-frame window))
> >
> > at the very end of the defun "display-buffer-reuse-window", the
> > problem goes away, i.e., in the above example, frame B gets input
> > focus after every invocation of occur in frame A. How can I get this
> > with a suitable customization on the "display-buffer-alist" level?
> 
> You can't.  I think the most simple way to achieve what you want is to
> add a function to 'occur-hook' that does search for a window that
> shows the current buffer and, if it finds such a window, invokes
> 'select-frame-set-input-focus' for that window's frame.
> 
> martin

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > Suppose, without any display-buffer-alist customization, I have just
 >
 > (setq display-buffer-base-action
 >         (quote (
 >    (display-buffer-reuse-window display-buffer-pop-up-frame)
 >    (reusable-frames . x)
 > )))
 >
 > in my init file, where x can be any of 0,1, nil, visible, all these
 > choices don’t matter for this: If I open Emacs, the initial frame
 > shows up, and any file loaded via recent-files, or by dragging on
 > the Emacs icon, or by clicking on the file icon, shows up in the
 > initial frame, contrary to what is advertised in the
 > manual.

What _is_ advertised in the manual?

 > However, once a file is loaded, then re-selecting it via
 > Menu->Buffers, pops it up in a new frame (with properties as
 > specified in defaults-frame-alist). So, what is the relation between
 > "display-buffer-base-action” and “default-frame-alist”?

If a new frame is created by 'display-buffer', its parameters are
determined by

(1) any 'pop-up-frame-parameters' entry found,

(2) the value of 'pop-up-frame-alist' (if the function specified by
     'pop-up-frame-function' processes it - the default does) and

(3) the value of 'default-frame-alist'.

So if you use the 'display-buffer-base-action' specification from the
top, only 'default-frame-alist' will be used because you neither
customized any 'pop-up-frame-parameters' nor 'pop-up-frame-alist' (the
latter should not be used anyway).  All based on the assumption that
you have customized 'switch-to-buffer-obey-display-actions' so that
Menu->Buffers indeed tries to pop to the buffer.

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

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



> Am 04.11.2019 um 10:06 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > Suppose, without any display-buffer-alist customization, I have just
> >
> > (setq display-buffer-base-action
> >         (quote (
> >    (display-buffer-reuse-window display-buffer-pop-up-frame)
> >    (reusable-frames . x)
> > )))
> >
> > in my init file, where x can be any of 0,1, nil, visible, all these
> > choices don’t matter for this: If I open Emacs, the initial frame
> > shows up, and any file loaded via recent-files, or by dragging on
> > the Emacs icon, or by clicking on the file icon, shows up in the
> > initial frame, contrary to what is advertised in the
> > manual.
> 
> What _is_ advertised in the manual?

To quote from Section 28.13.5:

Let's consider a user who, as a rule, prefers to display buffers on another frame. Such a user might provide the following customization:
     (customize-set-variable
      'display-buffer-base-action
      '((display-buffer-reuse-window display-buffer-pop-up-frame)
        (reusable-frames . 0)))
This setting will cause display-buffer to first try to find a window showing the buffer on a visible or iconified frame and, if no such frame exists, pop up a new frame.


The words  “another”  and “new”  suggest a behavior different from what I described above.


> 
> > However, once a file is loaded, then re-selecting it via
> > Menu->Buffers, pops it up in a new frame (with properties as
> > specified in defaults-frame-alist). So, what is the relation between
> > "display-buffer-base-action” and “default-frame-alist”?
> 
> If a new frame is created by 'display-buffer', its parameters are
> determined by
> 
> (1) any 'pop-up-frame-parameters' entry found,
> 
> (2) the value of 'pop-up-frame-alist' (if the function specified by
>    'pop-up-frame-function' processes it - the default does) and
> 
> (3) the value of 'default-frame-alist'.
> 
> So if you use the 'display-buffer-base-action' specification from the
> top, only 'default-frame-alist' will be used because you neither
> customized any 'pop-up-frame-parameters' nor 'pop-up-frame-alist' (the
> latter should not be used anyway).  All based on the assumption that
> you have customized 'switch-to-buffer-obey-display-actions' so that
> Menu->Buffers indeed tries to pop to the buffer.
> 
> martin
> 


[-- Attachment #2: Type: text/html, Size: 4466 bytes --]

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 >> What _is_ advertised in the manual?
 >
 > To quote from Section 28.13.5:
 >
 > Let's consider a user who, as a rule, prefers to display buffers on another frame. Such a user might provide the following customization:
 >       (customize-set-variable
 >        'display-buffer-base-action
 >        '((display-buffer-reuse-window display-buffer-pop-up-frame)
 >          (reusable-frames . 0)))
 > This setting will cause display-buffer to first try to find a window showing the buffer on a visible or iconified frame and, if no such frame exists, pop up a new frame.
 >
 >
 > The words  “another”  and “new”  suggest a behavior different from what I described above.

Right.  But this text talks about 'display-buffer' only.  When you
choose a buffer from the Buffers menu you invoke the function
specified by 'menu-bar-select-buffer-function' and the default for
that is ‘switch-to-buffer’ which does not, by default, invoke
'display-buffer'.  So the text you quote does not apply in this case.
It will apply though if you set 'menu-bar-select-buffer-function' to
'pop-to-buffer' or set 'switch-to-buffer-obey-display-actions' to a
non-nil value.

martin

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > I set 'switch-to-buffer-obey-display-actions’ to t, so to a non-nil value!

My bad.  According to its doc-string

   If non-nil, `switch-to-buffer' runs `pop-to-buffer-same-window' instead.

it just pops to the buffer in the same window and even using
'inhibit-same-window' won't prevent it from doing that.  So in this
particular case you have to set 'menu-bar-select-buffer-function' to
'pop-to-buffer'.

As for the general case I wouldn't know.  Juri, how about a special
value say 'strict' for 'switch-to-buffer-obey-display-actions' that
simply makes it behave like 'pop-to-buffer'?  Or at least obey
'inhibit-same-window'?  Those hard-coded 'switch-to-buffer' instances
are really hard to get by.

martin

bug#37840: Missing in the Emacs manuals:

[Juri Linkov]

>> I set 'switch-to-buffer-obey-display-actions’ to t, so to a non-nil value!
>
> My bad.  According to its doc-string
>
>   If non-nil, `switch-to-buffer' runs `pop-to-buffer-same-window' instead.
>
> it just pops to the buffer in the same window and even using
> 'inhibit-same-window' won't prevent it from doing that.  So in this
> particular case you have to set 'menu-bar-select-buffer-function' to
> 'pop-to-buffer'.
>
> As for the general case I wouldn't know.  Juri, how about a special
> value say 'strict' for 'switch-to-buffer-obey-display-actions' that
> simply makes it behave like 'pop-to-buffer'?  Or at least obey
> 'inhibit-same-window'?  Those hard-coded 'switch-to-buffer' instances
> are really hard to get by.

But pop-to-buffer-same-window still follows rules from
display-buffer-alist that can override inhibit-same-window.

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > But pop-to-buffer-same-window still follows rules from
 > display-buffer-alist that can override inhibit-same-window.

OK.  Then customizing 'display-buffer-base-action' and
'switch-to-buffer-obey-display-actions' alone is not sufficient for
overriding the behavior of 'switch-to-buffer'.  The user has to
customize 'display-buffer-alist' as well.

This means that for Konrad's scenario to work, the minimum requirement
is

(custom-set-variables
  '(display-buffer-base-action
    '((display-buffer-reuse-window display-buffer-pop-up-frame)
      (reusable-frames . 0)))
  '(display-buffer-alist
    '(("\\*.*\\*" . (nil (inhibit-same-window . t)))))
  '(switch-to-buffer-obey-display-actions t))

martin

bug#37840: Missing in the Emacs manuals:

[Juri Linkov]

>> But pop-to-buffer-same-window still follows rules from
>> display-buffer-alist that can override inhibit-same-window.
>
> OK.  Then customizing 'display-buffer-base-action' and
> 'switch-to-buffer-obey-display-actions' alone is not sufficient for
> overriding the behavior of 'switch-to-buffer'.  The user has to
> customize 'display-buffer-alist' as well.
>
> This means that for Konrad's scenario to work, the minimum requirement
> is
>
> (custom-set-variables
>  '(display-buffer-base-action
>    '((display-buffer-reuse-window display-buffer-pop-up-frame)
>      (reusable-frames . 0)))
>  '(display-buffer-alist
>    '(("\\*.*\\*" . (nil (inhibit-same-window . t)))))
>  '(switch-to-buffer-obey-display-actions t))

This doesn't look good, indeed.

Then maybe switch-to-buffer-obey-display-actions should be replaced
by another variable switch-to-buffer-display-function that could be
customized to possible options #'pop-to-buffer-same-window,
#'pop-to-buffer or any other custom function (and nil by default).

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 >> This means that for Konrad's scenario to work, the minimum requirement
 >> is
 >>
 >> (custom-set-variables
 >>   '(display-buffer-base-action
 >>     '((display-buffer-reuse-window display-buffer-pop-up-frame)
 >>       (reusable-frames . 0)))
 >>   '(display-buffer-alist
 >>     '(("\\*.*\\*" . (nil (inhibit-same-window . t)))))
 >>   '(switch-to-buffer-obey-display-actions t))
 >
 > This doesn't look good, indeed.
 >
 > Then maybe switch-to-buffer-obey-display-actions should be replaced
 > by another variable switch-to-buffer-display-function that could be
 > customized to possible options #'pop-to-buffer-same-window,
 > #'pop-to-buffer or any other custom function (and nil by default).

We can do whatever we think best as long as Emacs 27 is not out yet.

If we leave things as they are we should probably mention explicitly
that 'display-buffer-base-action' gets overridden when this option is
set.  We should also say how 'switch-to-buffer-preserve-window-point'
is or is not respected in that case (I'm slightly confused about how
it works now).

Otherwise, I see no need for renaming the option.  We could simply
allow its value to be an ordinary display action with functions and an
alist and have 'switch-to-buffer' act accordingly.  Or am I missing
something?

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

> Am 08.11.2019 um 10:20 schrieb martin rudalics <rudalics@gmx.at>:
> 
> >> This means that for Konrad's scenario to work, the minimum requirement
> >> is
> >>
> >> (custom-set-variables
> >>   '(display-buffer-base-action
> >>     '((display-buffer-reuse-window display-buffer-pop-up-frame)
> >>       (reusable-frames . 0)))
> >>   '(display-buffer-alist
> >>     '(("\\*.*\\*" . (nil (inhibit-same-window . t)))))
> >>   '(switch-to-buffer-obey-display-actions t))

While this works in most cases, for me it still gives a problem with Speedbar: Suppose frame A has input focus, showing buffer A. Open Speedbar via the menu. Then the Speedbar frame pops up, with input focus, but with the same layout as frame A had, and a frame B opens, with the layput intended for the Speedbar frame, but showing buffer A. 

Konrad

> >
> > This doesn't look good, indeed.
> >
> > Then maybe switch-to-buffer-obey-display-actions should be replaced
> > by another variable switch-to-buffer-display-function that could be
> > customized to possible options #'pop-to-buffer-same-window,
> > #'pop-to-buffer or any other custom function (and nil by default).
> 
> We can do whatever we think best as long as Emacs 27 is not out yet.
> 
> If we leave things as they are we should probably mention explicitly
> that 'display-buffer-base-action' gets overridden when this option is
> set.  We should also say how 'switch-to-buffer-preserve-window-point'
> is or is not respected in that case (I'm slightly confused about how
> it works now).
> 
> Otherwise, I see no need for renaming the option.  We could simply
> allow its value to be an ordinary display action with functions and an
> alist and have 'switch-to-buffer' act accordingly.  Or am I missing
> something?
> 
> martin

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > While this works in most cases, for me it still gives a problem with
 > Speedbar: Suppose frame A has input focus, showing buffer A. Open
 > Speedbar via the menu. Then the Speedbar frame pops up, with input
 > focus, but with the same layout as frame A had, and a frame B opens,
 > with the layput intended for the Speedbar frame, but showing buffer
 > A.

I cannot reproduce that here.  When with emacs -Q I ask to show the
speedbar from the Options menu, the speedbar pops up the same way
regardless of whether I have done these customizations or not.  Maybe
I don't understand the meaning of "layout".

What I did notice is that clicking on a file in the speedbar frame
always opens it in the same window of the initial frame thus maybe
disregarding the customizations but that's a different issue I
suppose.

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

> Am 08.11.2019 um 19:27 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > While this works in most cases, for me it still gives a problem with
> > Speedbar: Suppose frame A has input focus, showing buffer A. Open
> > Speedbar via the menu. Then the Speedbar frame pops up, with input
> > focus, but with the same layout as frame A had, and a frame B opens,
> > with the layput intended for the Speedbar frame, but showing buffer
> > A.
> 
> I cannot reproduce that here.  

I used this customization:

(custom-set-variables
'(display-buffer-base-action
  '((display-buffer-reuse-window display-buffer-pop-up-frame)
    (reusable-frames . 0)))
'(display-buffer-alist
  '((".*" . (nil (inhibit-same-window . t)))))
'(switch-to-buffer-obey-display-actions t))

to get new frames for any type of file, and then Speedbar popped up with a layout according to defaults-frame-alist; by “layout” I mean frame geometry, font, color etc. 

Konrad

> When with emacs -Q I ask to show the
> speedbar from the Options menu, the speedbar pops up the same way
> regardless of whether I have done these customizations or not.  Maybe
> I don't understand the meaning of "layout".
> 
> What I did notice is that clicking on a file in the speedbar frame
> always opens it in the same window of the initial frame thus maybe
> disregarding the customizations but that's a different issue I
> suppose.
> 
> martin

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > I used this customization:
 >
 > (custom-set-variables
 > '(display-buffer-base-action
 >    '((display-buffer-reuse-window display-buffer-pop-up-frame)
 >      (reusable-frames . 0)))
 > '(display-buffer-alist
 >    '((".*" . (nil (inhibit-same-window . t)))))
 > '(switch-to-buffer-obey-display-actions t))
 >
 > to get new frames for any type of file, and then Speedbar popped up
 > with a layout according to defaults-frame-alist; by “layout” I mean
 > frame geometry, font, color etc.

That means "any type of buffer" and is obviously too strong.  Unless
you make your regexp more stringent, you will see similar problems all
over your session.

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

> Am 09.11.2019 um 10:01 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > I used this customization:
> >
> > (custom-set-variables
> > '(display-buffer-base-action
> >    '((display-buffer-reuse-window display-buffer-pop-up-frame)
> >      (reusable-frames . 0)))
> > '(display-buffer-alist
> >    '((".*" . (nil (inhibit-same-window . t)))))
> > '(switch-to-buffer-obey-display-actions t))
> >
> > to get new frames for any type of file, and then Speedbar popped up
> > with a layout according to defaults-frame-alist; by “layout” I mean
> > frame geometry, font, color etc.
> 
> That means "any type of buffer" and is obviously too strong.  Unless
> you make your regexp more stringent, you will see similar problems all
> over your session.

So what is the correct customization if I wish to have _every_ buffer in its own (new) frame, just different buffer types having different frame types, the latter meaning different geometry, fonts etc.?


Konrad

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > So what is the correct customization if I wish to have _every_
 > buffer in its own (new) frame, just different buffer types having
 > different frame types, the latter meaning different geometry, fonts
 > etc.?

I'm afraid there's none.  The reason is a technical one.  The speedbar
code uses 'switch-to-buffer' internally to switch to its own buffer in
its own window on its own frame.  Any customization of
'switch-to-buffer' to do something like switch to _any_ buffer in
another frame will make the speedbar choke because its buffer won't be
displayed in the same window where it expects it.

Note that 'switch-to-buffer-obey-display-actions' is a new addition
that has not been yet tested extensively.  In earlier versions you had
no possibility customizing the behavior of 'switch-to-buffer'.  In
practice, it always used the selected window for displaying the
buffer.

You could try to replace the regexp in 'display-buffer-alist' with a
function that filters out all buffers that are in a sense special like
the speedbar buffer but I'm afraid that you will encounter too many
instances of internal uses of 'switch-to-buffer' so you will soon or
later get tired of such an approach.

The other approach is to specify in that function all buffers that
interest you (mostly based on the extension of the file they visit)
instead of _every_ buffer.  Would that be so difficult?

Finally, note that if you make sure that practically all windows you
use are strongly dedicated to their buffers, 'switch-to-buffer' calls
will respect that.  For example, if with emacs -Q I do

(custom-set-variables
  '(display-buffer-base-action
    '((display-buffer-reuse-window display-buffer-pop-up-frame)
      (dedicated . t)
      (reusable-frames . 0))))

(set-window-dedicated-p nil t)

and then choose *Messages* from the Buffers menu, it will pop up in a
new frame and the speedbar will work normally.  Note, however, that
strongly dedicated windows may have other disadvantages you will have
to get used to.

martin

bug#37840: Missing in the Emacs manuals:

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Sun, 10 Nov 2019 19:33:17 +0100
> Cc: 37840@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
> 
> The speedbar code uses 'switch-to-buffer' internally to switch to
> its own buffer in its own window on its own frame.  Any
> customization of 'switch-to-buffer' to do something like switch to
> _any_ buffer in another frame will make the speedbar choke because
> its buffer won't be displayed in the same window where it expects
> it.

That seems unfortunate.  Can we somehow make Speedbar insulated from
the switch-to-buffer customizations?

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

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

 > That seems unfortunate.  Can we somehow make Speedbar insulated from
 > the switch-to-buffer customizations?

The attached patch should do that.  But there are probably too many
similar cases out there.  Strictly spoken we should check each of our
'switch-to-buffer' calls for whether to

(1) convert it to 'set-window-buffer' (so no customization ever
     affects it),

(2) bind 'switch-to-buffer-obey-display-actions' to nil around it (to
     bow out comme il faut when the window is a minibuffer window or
     dedicated to its buffer),

(3) call 'pop-to-buffer-same-window' instead, or

(4) leave it alone.

martin

[-- Attachment #2: dframe.diffs --]
[-- Type: text/plain, Size: 903 bytes --]

--- a/lisp/dframe.el
+++ b/lisp/dframe.el
@@ -309,8 +309,8 @@ dframe-frame-mode
 	  (make-frame-visible (symbol-value frame-var))
 	  (select-frame (symbol-value frame-var))
 	  (set-window-dedicated-p (selected-window) nil)
-	  (if (not (eq (current-buffer) (symbol-value buffer-var)))
-	      (switch-to-buffer (symbol-value buffer-var)))
+	  (unless (eq (current-buffer) (symbol-value buffer-var))
+	    (set-window-buffer nil (symbol-value buffer-var)))
 	  (set-window-dedicated-p (selected-window) t)
 	  (raise-frame (symbol-value frame-var))
 	  )
@@ -346,7 +346,7 @@ dframe-frame-mode
 	;; Put the buffer into the frame
 	(save-excursion
 	  (select-frame (symbol-value frame-var))
-	  (switch-to-buffer (symbol-value buffer-var))
+	  (set-window-buffer nil (symbol-value buffer-var))
 	  (set-window-dedicated-p (selected-window) t))
 	;; Run hooks (like reposition)
 	(run-hooks create-hook)

bug#37840: Missing in the Emacs manuals:

[Eli Zaretskii]

> Cc: konrad.podczeck@univie.ac.at, 37840@debbugs.gnu.org, juri@linkov.net
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 14 Nov 2019 19:18:48 +0100
> 
>  > That seems unfortunate.  Can we somehow make Speedbar insulated from
>  > the switch-to-buffer customizations?
> 
> The attached patch should do that.

LGTM, thanks.

> But there are probably too many similar cases out there.  Strictly
> spoken we should check each of our 'switch-to-buffer' calls for
> whether to
> 
> (1) convert it to 'set-window-buffer' (so no customization ever
>      affects it),
> 
> (2) bind 'switch-to-buffer-obey-display-actions' to nil around it (to
>      bow out comme il faut when the window is a minibuffer window or
>      dedicated to its buffer),
> 
> (3) call 'pop-to-buffer-same-window' instead, or
> 
> (4) leave it alone.

I think you are right.  Volunteers are welcome.

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 >> The attached patch should do that.
 >
 > LGTM, thanks.

Installed.

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

> 
> The other approach is to specify in that function all buffers that
> interest you (mostly based on the extension of the file they visit)
> instead of _every_ buffer.  Would that be so difficult?
> 



> 
> The other approach is to specify in that function all buffers that
> interest you (mostly based on the extension of the file they visit)
> instead of _every_ buffer.  Would that be so difficult?
> 


I followed this advice, and the new display-buffer customization mechanism works indeed great. However,  the following problem arises. Suppose I have the customization

(customize-set-variable 'display-buffer-base-action
  '((display-buffer-reuse-window display-buffer-pop-up-frame)
    (reusable-frames . t)))

(customize-set-variable 'display-buffer-alist
     '(("\\`\\*[^s][^s].*\\*\\'"
      (display-buffer-reuse-window display-buffer-pop-up-frame)
       (dedicated . t)
       (pop-up-frame-parameters
       (width . 83)
       (height . 42)
       (left . 778)
       (unsplittable)
       (tool-bar-lines . 0)
       (left-fringe . 0)
       (right-fringe . 0)
       (line-spacing . 0)
       (font . "Monaco-12")
       (top . 110)
       ))
    ("[.]"
      (display-buffer-reuse-window display-buffer-pop-up-frame)
       (pop-up-frame-parameters
       (tool-bar-lines . 1)
       (left . 1)
       (left-fringe . 2)
       (top . 0)
       (height . 46)
       (width . 80)
       (font . "SF MONO-15")
       (line-spacing . 3)
      ))))

With this, start Emacs, open a file, foo.tex say, and in the mini-buffer of the frame displaying foo.tex do occur->some text, so that the occur-buffer displays in its own frame. Now, in the mini-buffer of the frame with foo.tex do bury-buffer. Then also this frame displays the occur-buffer, so that I end up with two frames displaying the same occur-buffer.  How to solve this problem?

Konrad

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

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

 > With this, start Emacs, open a file, foo.tex say, and in the
 > mini-buffer of the frame displaying foo.tex do occur->some text, so
 > that the occur-buffer displays in its own frame. Now, in the
 > mini-buffer of the frame with foo.tex do bury-buffer. Then also this
 > frame displays the occur-buffer, so that I end up with two frames
 > displaying the same occur-buffer.  How to solve this problem?

You can't and I am to blame for that.  'switch-to-visible-buffer' is
simply too weak to handle your case.  Please apply the attached patch
and set 'switch-to-buffer-skip-visible' to 'visible or t.

Eli this was a regression in Emacs 24 that went unnoticed so far.  Any
objections to install?

martin

[-- Attachment #2: switch-to-buffer-skip-visible.diffs --]
[-- Type: text/plain, Size: 5810 bytes --]

diff --git a/lisp/window.el b/lisp/window.el
index 7478047939..5e43c73ef3 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -4409,6 +4409,35 @@ switch-to-visible-buffer
   :version "24.1"
   :group 'windows)
 
+(make-obsolete-variable 'switch-to-visible-buffer
+                        'switch-to-buffer-skip-visible "27.1")
+
+(defcustom switch-to-buffer-skip-visible nil
+  "If nil, allow switching to an already visible buffer.
+If this variable is nil, `switch-to-prev-buffer' and
+`switch-to-next-buffer' allow switching to a buffer that is
+already visible in a window.
+
+If this variable is non-nil, it specifies the frames to skip when
+a window on that frame already shows the buffer.  In particular:
+
+- t means all windows on all existing frames.
+
+- `visible' means all windows on all visible frames.
+
+- 0 (the number zero) means all windows on all visible and
+    iconified frames.
+
+- `this' means all windows on the same frame only."
+  :type
+  '(choice (const :tag "Never" nil)
+	   (const :tag "Any frame" t)
+	   (const :tag "Visible frames" visible)
+	   (const :tag "Visible and iconified frames" 0)
+           (const :tag "This frame" this))
+  :version "27.1"
+  :group 'windows)
+
 (defun switch-to-prev-buffer (&optional window bury-or-kill)
   "In WINDOW switch to previous buffer.
 WINDOW must be a live window and defaults to the selected one.
@@ -4424,6 +4453,10 @@ switch-to-prev-buffer
 future invocation of `switch-to-prev-buffer' less likely switches
 to it.
 
+The option `switch-to-buffer-skip-visible' controls whether
+switching to a buffer already visible in another window is
+allowed.
+
 This function is called by `prev-buffer'."
   (interactive)
   (let* ((window (window-normalize-window window t))
@@ -4433,7 +4466,14 @@ switch-to-prev-buffer
 	 ;; Save this since it's destroyed by `set-window-buffer'.
 	 (next-buffers (window-next-buffers window))
          (pred (frame-parameter frame 'buffer-predicate))
-	 entry new-buffer killed-buffers visible)
+         (skip-visible
+          (cond
+           ((memq switch-to-buffer-skip-visible '(t visible 0))
+            switch-to-buffer-skip-visible)
+           ((or switch-to-buffer-skip-visible
+                (not switch-to-visible-buffer))
+            frame)))
+         entry new-buffer killed-buffers visible)
     (when (window-minibuffer-p window)
       ;; Don't switch in minibuffer window.
       (unless (setq window (minibuffer-selected-window))
@@ -4456,8 +4496,7 @@ switch-to-prev-buffer
 		   ;; When BURY-OR-KILL is nil, avoid switching to a
 		   ;; buffer in WINDOW's next buffers list.
 		   (or bury-or-kill (not (memq new-buffer next-buffers))))
-	  (if (and (not switch-to-visible-buffer)
-		   (get-buffer-window new-buffer frame))
+          (if (and skip-visible (get-buffer-window new-buffer skip-visible))
 	      ;; Try to avoid showing a buffer visible in some other
 	      ;; window.
 	      (setq visible new-buffer)
@@ -4482,8 +4521,7 @@ switch-to-prev-buffer
                      ;; Don't show a buffer shown in a side window before.
                      (not (buffer-local-value 'window--sides-shown buffer))
                      (or bury-or-kill (not (memq buffer next-buffers))))
-            (if (and (not switch-to-visible-buffer)
-                     (get-buffer-window buffer frame))
+            (if (and skip-visible (get-buffer-window buffer skip-visible))
                 ;; Try to avoid showing a buffer visible in some other window.
                 (unless visible
                   (setq visible buffer))
@@ -4547,7 +4585,13 @@ switch-to-next-buffer
   "In WINDOW switch to next buffer.
 WINDOW must be a live window and defaults to the selected one.
 Return the buffer switched to, nil if no suitable buffer could be
-found.  This function is called by `next-buffer'."
+found.
+
+The option `switch-to-buffer-skip-visible' controls whether
+switching to a buffer already visible in another window is
+allowed.
+
+This function is called by `next-buffer'."
   (interactive)
   (let* ((window (window-normalize-window window t))
 	 (frame (window-frame window))
@@ -4555,6 +4599,13 @@ switch-to-next-buffer
 	 (old-buffer (window-buffer window))
 	 (next-buffers (window-next-buffers window))
          (pred (frame-parameter frame 'buffer-predicate))
+         (skip-visible
+          (cond
+           ((memq switch-to-buffer-skip-visible '(t visible 0))
+            switch-to-buffer-skip-visible)
+           ((or switch-to-buffer-skip-visible
+                (not switch-to-visible-buffer))
+            frame)))
 	 new-buffer entry killed-buffers visible)
     (when (window-minibuffer-p window)
       ;; Don't switch in minibuffer window.
@@ -4589,8 +4640,7 @@ switch-to-next-buffer
                      ;; Don't show a buffer shown in a side window before.
                      (not (buffer-local-value 'window--sides-shown buffer))
                      (not (assq buffer (window-prev-buffers window))))
-            (if (and (not switch-to-visible-buffer)
-                     (get-buffer-window buffer frame))
+            (if (and skip-visible (get-buffer-window buffer skip-visible))
                 ;; Try to avoid showing a buffer visible in some other window.
                 (setq visible buffer)
               (setq new-buffer buffer)
@@ -4605,8 +4655,7 @@ switch-to-next-buffer
 				  (cons new-buffer killed-buffers))))
 		   (not (eq new-buffer old-buffer))
                    (or (null pred) (funcall pred new-buffer)))
-	  (if (and (not switch-to-visible-buffer)
-		   (get-buffer-window new-buffer frame))
+          (if (and skip-visible (get-buffer-window new-buffer skip-visible))
 	      ;; Try to avoid showing a buffer visible in some other window.
 	      (unless visible
 		(setq visible new-buffer))

bug#37840: Missing in the Emacs manuals:

[Eli Zaretskii]

> From: martin rudalics <rudalics@gmx.at>
> Date: Fri, 22 Nov 2019 18:49:42 +0100
> Cc: 37840@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
> 
> Eli this was a regression in Emacs 24 that went unnoticed so far.  Any
> objections to install?

Any reasons I should consider to object?

Thanks.

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

The patch does not do the job. With the customization from my previous mail, start Emacs, open, say, foo.tex, and then do occur->some text. In the frame with the occur buffer, do bury buffer, so that the frame with the occur-buffer becomes iconified, so everything is good up to now. But then, doing bury buffer in the frame displaying foo.tex, the message-buffer displays in that frame, then doing again bury-buffer in that frame, the occur-buffer shows up, again in the frame originally intended for foo.tex, that is in the wrong frame, i.e., not as intended with the display-buffer-alist customization.

Would it not be better to adopt a more radical approach? Say that there are two basic defaults between which a user can choose: one as it is now, and a second one where there is a strict one-to-one correspondence between buffers and frames (i.e., in the terminology of Emacs, with no “windows” at all). Given the second basis default, the user could then customize whether for some buffer-types he/she wants to have them displayed in windows, or, depending on the buffer-type, customize geometry, fonts etc. of frames.

Konrad

> Am 22.11.2019 um 20:22 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
>> From: martin rudalics <rudalics@gmx.at>
>> Date: Fri, 22 Nov 2019 18:49:42 +0100
>> Cc: 37840@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
>> 
>> Eli this was a regression in Emacs 24 that went unnoticed so far.  Any
>> objections to install?
> 
> Any reasons I should consider to object?
> 
> Thanks.

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > The patch does not do the job. With the customization from my
 > previous mail, start Emacs, open, say, foo.tex, and then do
 > occur->some text. In the frame with the occur buffer, do bury
 > buffer, so that the frame with the occur-buffer becomes iconified,
 > so everything is good up to now. But then, doing bury buffer in the
 > frame displaying foo.tex, the message-buffer displays in that frame,
 > then doing again bury-buffer in that frame, the occur-buffer shows
 > up, again in the frame originally intended for foo.tex, that is in
 > the wrong frame, i.e., not as intended with the display-buffer-alist
 > customization.

If you want to keep the occur-buffer in an iconified frame, you have
to customize 'switch-to-buffer-skip-visible' to 0 or t in order to
avoid switching to it automatically in another window.  When I do that
here, 'bury-buffer' switches between foo.tex, *scratch* and *Messages*
only.

 > Would it not be better to adopt a more radical approach? Say that
 > there are two basic defaults between which a user can choose: one as
 > it is now, and a second one where there is a strict one-to-one
 > correspondence between buffers and frames (i.e., in the terminology
 > of Emacs, with no “windows” at all). Given the second basis default,
 > the user could then customize whether for some buffer-types he/she
 > wants to have them displayed in windows, or, depending on the
 > buffer-type, customize geometry, fonts etc. of frames.

I suppose that by customizing 'switch-to-buffer-skip-visible' to t and
using a 'display-buffer-alist' that always makes a new dedicated frame
that becomes invisible when it gets buried, you can largely achieve
that.  The only problems should result from internal Emacs functions
that by default try to reuse or split the selected window.  I'm quite
sure that nothing can be done in this regard anyway.

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

I just noted that the ediff-control-panel does not react on any of the display-buffer-alist possibilities to customize appearance of frames.

Konrad

> Am 23.11.2019 um 09:16 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > The patch does not do the job. With the customization from my
> > previous mail, start Emacs, open, say, foo.tex, and then do
> > occur->some text. In the frame with the occur buffer, do bury
> > buffer, so that the frame with the occur-buffer becomes iconified,
> > so everything is good up to now. But then, doing bury buffer in the
> > frame displaying foo.tex, the message-buffer displays in that frame,
> > then doing again bury-buffer in that frame, the occur-buffer shows
> > up, again in the frame originally intended for foo.tex, that is in
> > the wrong frame, i.e., not as intended with the display-buffer-alist
> > customization.
> 
> If you want to keep the occur-buffer in an iconified frame, you have
> to customize 'switch-to-buffer-skip-visible' to 0 or t in order to
> avoid switching to it automatically in another window.  When I do that
> here, 'bury-buffer' switches between foo.tex, *scratch* and *Messages*
> only.
> 
> > Would it not be better to adopt a more radical approach? Say that
> > there are two basic defaults between which a user can choose: one as
> > it is now, and a second one where there is a strict one-to-one
> > correspondence between buffers and frames (i.e., in the terminology
> > of Emacs, with no “windows” at all). Given the second basis default,
> > the user could then customize whether for some buffer-types he/she
> > wants to have them displayed in windows, or, depending on the
> > buffer-type, customize geometry, fonts etc. of frames.
> 
> I suppose that by customizing 'switch-to-buffer-skip-visible' to t and
> using a 'display-buffer-alist' that always makes a new dedicated frame
> that becomes invisible when it gets buried, you can largely achieve
> that.  The only problems should result from internal Emacs functions
> that by default try to reuse or split the selected window.  I'm quite
> sure that nothing can be done in this regard anyway.
> 
> martin
> 

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > I just noted that the ediff-control-panel does not react on any of
 > the display-buffer-alist possibilities to customize appearance of
 > frames.

Customize 'ediff-control-frame-position-function'.  You can stuff
anything you want into the return value of that function, not just the
location.  Consult 'ediff-control-frame-parameters' in ediff-wind.el
for how ediff sets things up if you do not interfere.

And be aware that Emacs has many other frame creating packages that
disregard 'display-buffer-alist'.

martin

bug#37840: Missing in the Emacs manuals:

[Konrad Podczeck]

Hi,

I cannot solve the following problem with Ediff:


Suppose I have two buffers open, say fooA.tex and fooB.tex, each in its own frame. Then I invoke Ediff to compare both buffers. Now suppose I kill the buffers fooA.tex and fooB.tex _before_ I quit the Ediff control panel. If I then quit the Ediff control buffer, it happens that some of the auxiliary Ediff buffers pops up, but _not_ in the geometry customized with display-buffer-alist for *something* type buffers, but with a geometry according to default-frame-list modulo that the position is that of one of the former frames for fooA.tex or fooB.tex, depending on which was buffer A in Ediff's terminology. Thus, I can get a total frame layout which should not exist according to the customizations according to default-frame-alist and display-buffer-alist. 

How can I sole this? Or, even better, how can I manage that in the above scenario no buffer pops up if I close the Ediff control panel? Has the problem maybe something to do with the fact that the frame of the Ediff control panel has no minibuffer?

Thanks,

Konrad



> Am 26.11.2019 um 10:32 schrieb martin rudalics <rudalics@gmx.at>:
> 
> > I just noted that the ediff-control-panel does not react on any of
> > the display-buffer-alist possibilities to customize appearance of
> > frames.
> 
> Customize 'ediff-control-frame-position-function'.  You can stuff
> anything you want into the return value of that function, not just the
> location.  Consult 'ediff-control-frame-parameters' in ediff-wind.el
> for how ediff sets things up if you do not interfere.
> 
> And be aware that Emacs has many other frame creating packages that
> disregard 'display-buffer-alist'.
> 
> martin

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > Suppose I have two buffers open, say fooA.tex and fooB.tex, each in
 > its own frame. Then I invoke Ediff to compare both buffers. Now
 > suppose I kill the buffers fooA.tex and fooB.tex _before_

... but here already something must happen in any windows resp. frames
showing these buffers ...

 > I quit the
 > Ediff control panel. If I then quit the Ediff control buffer, it
 > happens that some of the auxiliary Ediff buffers pops up, but _not_
 > in the geometry customized with display-buffer-alist for *something*
 > type buffers, but with a geometry according to default-frame-list
 > modulo that the position is that of one of the former frames for
 > fooA.tex or fooB.tex, depending on which was buffer A in Ediff's
 > terminology. Thus, I can get a total frame layout which should not
 > exist according to the customizations according to
 > default-frame-alist and display-buffer-alist.

Note again that ediff doesn't care neither about ‘default-frame-alist’
nor 'display-buffer-alist'.  It uses its own customary settings and
sometimes relies on 'switch-to-buffer' to DTRT.  In addition, ediff
doesn't like it much when you kill one of its buffers too early, that
is before calling 'ediff-quit'.

You have two ways to interfere here: 'ediff-cleanup-hook' to clean up
the state _before_ 'ediff-quit' starts its own cleanup routine (so you
can, for example, delete frames showing buffers used by ediff) or
‘ediff-quit-hook’ which by default runs ediff's own cleanup function
'ediff-cleanup-mess' (where you will see a plethora of 'delete-window'
and 'switch-to-buffer' calls that probably cause the behavior you see
and dislike above).  If you want to change or add to the latter, it's
probably best to run 'ediff-cleanup-mess' through the debugger first
in order to understand how it works and how it messes up your
buffer/frame relationships.

 > How can I sole this? Or, even better, how can I manage that in the
 > above scenario no buffer pops up if I close the Ediff control panel?
 > Has the problem maybe something to do with the fact that the frame
 > of the Ediff control panel has no minibuffer?

You cannot give a minibuffer window to a frame that has none.  So by
all means, 'ediff-quit' should avoid reusing the control panel frame
for showing another buffer.  Does it do that in your case?

martin

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

> Any reasons I should consider to object?

None so far.

martin

bug#37840: Missing in the Emacs manuals:

[Eli Zaretskii]

> Cc: konrad.podczeck@univie.ac.at, 37840@debbugs.gnu.org, juri@linkov.net
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 23 Nov 2019 09:15:30 +0100
> 
> > Any reasons I should consider to object?
> 
> None so far.

Then please go ahead, and thanks.

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 > Then please go ahead, and thanks.

The new option is now called 'switch-to-prev-buffer-skip' and also
accepts a function as value.  Hence Konrad can write, for example,

(defun no-occur (window buffer bury-or-kill)
   (string-equal (buffer-name buffer) "*Occur*"))

(setq switch-to-prev-buffer-skip 'no-occur)

so *Occur* will never be shown automatically, even if it is not
displayed on any frame at all.

martin

bug#37840: Missing in the Emacs manuals:

[martin rudalics]

 >  > Then please go ahead, and thanks.

And sorry for messing up the commit message.

martin

bug#37840: Missing in the Emacs manuals:

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Any reasons I should consider to object?
>> 
>> None so far.
>
> Then please go ahead, and thanks.

It looks like the patch was applied (with some changes).  Skimming the
rest of the thread, other related issues were discussed, but if I'm
reading it correctly, it seems like the described scenarios are now
possible with the patch installed.

So there doesn't seem to be anything further to be done in this bug
report, and I'm closing it.  If there are any further issues in this
area, perhaps opening a new bug report would be the way to go.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#37840: Missing in the Emacs manuals:

[Juri Linkov]

>> Then maybe switch-to-buffer-obey-display-actions should be replaced
>> by another variable switch-to-buffer-display-function that could be
>> customized to possible options #'pop-to-buffer-same-window,
>> #'pop-to-buffer or any other custom function (and nil by default).
>
> We can do whatever we think best as long as Emacs 27 is not out yet.
>
> If we leave things as they are we should probably mention explicitly
> that 'display-buffer-base-action' gets overridden when this option is
> set.  We should also say how 'switch-to-buffer-preserve-window-point'
> is or is not respected in that case (I'm slightly confused about how
> it works now).
>
> Otherwise, I see no need for renaming the option.  We could simply
> allow its value to be an ordinary display action with functions and an
> alist and have 'switch-to-buffer' act accordingly.  Or am I missing
> something?

I agree.  Adding support for display actions with functions to the
existing variable seems the best solution that would cover more use cases.