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

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

bug#37840: Missing in the Emacs manuals:


From: Konrad Podczeck
Subject: bug#37840: Missing in the Emacs manuals:
Date: Wed, 30 Oct 2019 21:37:07 +0100

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






reply via email to

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