[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: |
Sat, 14 Jul 2012 18:19:59 +0200 |
> In the problematic contexts, a new frame is popped up and given the focus (by
MS
> Windows). That is apparently somehow different from starting from a frame
that
> already has the focus.
OK. What happens if in in `yes-or-no-p' you use
(when minibuffer-auto-raise
(select-frame-set-input-focus
(window-frame (minibuffer-window))))
instead of `raise-frame'?
> If I had to guess blindly, I'd guess that it has to do with the
> timing/sequencing of things: Maybe in the problematic case the question is
FIRST
> posed in the minibuffer/echo area (giving the minibuffer frame focus) and THEN
> the new frame is popped up and it gets the focus.
I suppose `handle-switch-frame' is called after the `yes-or-no-p'. Then
even the `select-frame-set-input-focus' would not help.
> Whereas maybe in the case I just tested the focus never comes back to the
frame
> that originally had it - once the focus goes to the minibuffer frame, there is
> nothing that puts it back in the original frame. Just a hunch.
>
> If that is the case, maybe a fix (ugly hack) would be to do this: Whenever the
> minibuffer frame has focus and some other frame is created, immediately return
> focus to the minibuffer frame. (Dunno _how_ that might be done.)
What happens if in `with-temp-buffer-window' you add a
`save-selected-window' around
(with-current-buffer ,buffer
(setq ,value (progn ,@body))
(setq ,window (temp-buffer-window-show ,buffer)))
> Or perhaps look to what Dired does...
Dired uses a `save-window-excursion' which doesn't deal with the frame
but restores the selected window - maybe that's the reason.
> 1. FYI - I can test only with 24.1, not something later, since other bugs
still
> prevent my using the later Windows builds. I'm still waiting for a build more
> recent than 2012-07-02. Dunno whether this matters here.
What I sent should work with 24.1.
> 2. I tried to quit Emacs (C-x C-c) after creating a shell buffer (which is in
a
> dedicated window in a separate frame).
>
> The informative buffer that lists the active processes was popped up correctly
> in a separate frame as the yes-or-no question was asked. But when I tried to
> type yes or no, that typed input appeared nowhere.
>
> I would guess, from the fact that Windows gives the new frame the input focus,
> that that new frame had the focus and the input was trying to go there. But
> that buffer is created read-only and I saw no error message indicating that
> Emacs was trying to insert the input (yes/no) into a read-only buffer. No
> feedback at all - it's as if my typed input was silently sent to /dev/null.
> (That in itself is not good.)
>
> In any case, what's important is that the typed input did not go to the
> minibuffer frame.
Can you try with just `pop-up-frames' t, that is, disabling special
display buffers?
> [...]
> I thought that the patch I sent for this was going to be applied to Emacs -
but
> it never was. I use this code everyday, with no problem. But the dialog is
> still broken in vanilla Emacs.
I understand your concerns. But we have to first find out why your
system behaves differently and then try to find a general solution.
BTW, has bug#11566 been resolved meanwhile?
martin
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/13
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/14
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/14
- 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/14
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/15
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/15
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/15
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/15
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/16
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/16
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/16
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/16
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/16