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: Mon, 23 Jul 2012 09:12:00 -0700

>  >>  > 1. When I do C-x C-c, and respond to the yes/no question,
>  >>  > it seems I must wait a tiny bit before typing yes/no.
>  >>  > Otherwise, the first char (e.g. `y') is lost, so
>  >>  > I end up with just `es' (I see the `y' nowhere).  Not a
>  >>  > big deal; just FYI.
>  >>
>  >> Does this happen _only_ with your code or also in the emacs
>  >> -Q scenarios _without_ your code?  What happens with a
>  >> `y-or-no-p' defalias?
>  >
>  > Not sure what you mean.  There is no equivalent in the 
>  > emacs -Q tests you asked me to do.  There is nothing on
>  > post-command-hook etc.
> 
> So the delay is due to processing `post-command-hook'?

Is that a question or an answer? ;-)

If it is a question, I don't have the answer.  I can only report the symptom:
the first char is seemingly lost (does not show up in the minibuffer, at least,
and I have not seen it anywhere else).

As I said, this is not a big deal.  I mention it FYI.

>  >> 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.).
> 
> Here (Emacs 24.1 release because trunk crashes to frequently 
> these days) I can do something like
> 
> (progn
> ;;  (setq minibuffer-auto-raise t)
> ;;  (setq pop-up-frame-function
> ;;        (lambda () (make-frame '((minibuffer . nil)))))
>    (setq pop-up-frames t)
>    (add-hook 'after-make-frame-functions
> 	    #'(lambda (frame)
> 		(redirect-frame-focus frame frame)))
>    (shell))
> 
> where the two forms in comments are optional.  In all cases, focus is
> redirected appropriately after C-x C-c (although I think that when the
> new frame does have a minibuffer window, no redirection should be done
> at all and the prompt should appear in the new frame - but it seems
> difficult to get that right).  And obviously things look better with
> `minibuffer-auto-raise' non-nil.

Yes, if I try that with emacs -Q then it does what you say (with Emacs 24.1 and
later).

And uncommenting those two lines also behaves as I think you intend.  In both
cases, the question is posed, and the response is accepted, in the minibuffer of
frame *shell* (i.e., not the minibuffer of frame *Process List* in the case
where it has one).

But if *Process List* has no minibuffer (uncommented test case), and it is
selected (e.g., later, manually, after replying "no" once) when you hit `C-x
C-c' (i.e., the second `C-x C-c'), then frame *shell* is raised and receives the
input, even though there is nothing on that frame that the user needs to see
(apart from the question/answer).

It is better, IMO, for the question/response to be in frame *Process List*, as
we discussed earlier.  (This is all for the case where there is no standalone
minibuffer frame.)

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.

Previous Next

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