bug#37840: Missing in the Emacs manuals:

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

bug#37840: Missing in the Emacs manuals:

Konrad Podczeck
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 <[hidden email]>:

> 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

Reply | Threaded
Open this post in threaded view
|

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




Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>
> > 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
>




Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>
> > 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




Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>
> >        (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




Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>
> > 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




Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:
>
> > 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




Reply | Threaded
Open this post in threaded view
|

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




Reply | Threaded
Open this post in threaded view
|

bug#37840: Missing in the Emacs manuals:

Konrad Podczeck


Am 04.11.2019 um 10:06 schrieb martin rudalics <[hidden email]>:

> 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


Reply | Threaded
Open this post in threaded view
|

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




Reply | Threaded
Open this post in threaded view
|

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




Reply | Threaded
Open this post in threaded view
|

bug#37840: Missing in the Emacs manuals:

Juri Linkov-2
>> 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.



Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

bug#37840: Missing in the Emacs manuals:

Juri Linkov-2
>> 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).



12