GNU bug report logs - #11939
24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

Previous Next

Full log

View this message in rfc822 format

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 11939 <at> debbugs.gnu.org
Subject: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls	`list-processes'
Date: Wed, 25 Jul 2012 08:02:27 -0700

>  > The reason I provided the description I did was that I 
>  > thought we were talking about my setup with a standalone
>  > minibuffer frame.  See my previous description
>  > (quoted above) for what happens in that context.  For that 
>  > context, your suggestion of using `after-make-frame-functions',
>  > as I understood it, did not help.
> 
> What precisely is the problem with it?

(As I said, it was quoted above.)  Here again is what I reported (2012-07-22)
after that test:

> > > Anyway, it seems we are very close, for my needs.  I suppose I
> > > can put that redirection on `post-command-hook' (instead of in
> > > `1on1-fit-minibuffer-frame', which some oneonone.el users will
> > > not use), and things should generally work.
> >
> > That's a bad idea in my opinion.  Redirect as soon as possible.  Why
> > don't you use `after-make-frame-functions'?
> 
> I'm not sure what you mean.  I tried this:
> 
> 1. Remove the `redirect...' from `1on1-fit-minibuffer-frame'.
> 
> 2. Put back the guard
> (eq last-event-frame (window-frame (minibuffer-window)))
> at the beginning of `1on1-fit-minibuffer-frame' (so it is a 
> no-op otherwise).
> 
> 3. Defined this and added it to `after-make-frame-functions':
> 
> (defun 1on1-redirect-to-minibuffer (new-frame)
>   "..."
>   (when (and 1on1-fit-minibuffer-frame-flag
>              (active-minibuffer-window)
>              (save-selected-window
>                (select-window (minibuffer-window))
>                (one-window-p nil 'selected-frame)))
>     (redirect-frame-focus
>       new-frame
>       (window-frame (minibuffer-window)))))
> 
> That did not help at all.  The original symptoms returned 
> (typing yes/no did not go to the minibuffer etc.).

IOW, that was the same as doing nothing at all: the minibuffer frame did not
receive the yes/no user input.

So far, the most successful "fix" for my setup seems to be a combination of (a)
your code (`with-temp-buffer-window.el') plus (b) either (i) calling
`redirect-frame-focus' or `select-frame-set-input-focus' at the end of
`1on1-fit-minibuffer-frame' or (ii) using the guard (eq last-event-frame
(window-frame (minibuffer-window))) at the beginning of that function.

As I said, some users of oneonone.el won't also use fit-frame.el, so for them
putting a fix into `1on1-fit-minibuffer-frame' won't help.  I speculated to you
about putting the focus redirection instead on `post-command-hook', but you said
that was a bad idea and proposed to "use `after-make-frame-functions'".  I am
not sure what you meant by that, but the test above, which uses that hook, did
not work, in any case: the input was not redirected to the minibuffer frame.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.