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