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

Previous Next

Full log

Message #188 received at 11939 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 11939 <at> debbugs.gnu.org
Subject: Re: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus
	when it calls	`list-processes'
Date: Tue, 24 Jul 2012 14:46:55 +0200

>> (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).

This is probably the case where a window on another frame is reused
before asking the `yes-or-no-p' question.  This should be easier to
handle because the window manager supposedly won't focus that frame.

In any case I think a `yes-or-no-p' question should terminate by
killing the *Process List* buffer to avoid such confusion.

> 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.)

I think so too.

> 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?

martin

Previous Next

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