[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
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes', (continued)
- Message not available
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes', Drew Adams, 2012/07/29
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes', martin rudalics, 2012/07/30
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/26
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/26
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/23
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/23
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes',
martin rudalics <=
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/25
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/26
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/16