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: Sat, 2 Nov 2019 22:47:40 +0100

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






reply via email to

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