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

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

bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when i


From: martin rudalics
Subject: 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





reply via email to

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