[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: |
Sun, 22 Jul 2012 10:48:47 +0200 |
>> > I imagine that your code is applicable only to Emacs 24+
>> > (is that right?), so it could not have
>> > helped fix things with my setup for other Emacs versions.
>>
>> Yes. But maybe you could adapt your buffer display function
>> accordingly.
>
> What do you mean?
Write you own version of `special-display-popup-frame' replacing
(let* ((frame
(with-current-buffer buffer
(make-frame (append args special-display-frame-alist))))
(window (frame-selected-window frame)))
(display-buffer-record-window 'frame window buffer)
(set-window-dedicated-p window t)
with something like
(let* ((frame
(with-current-buffer buffer
(make-frame (append args special-display-frame-alist))))
(window (frame-selected-window frame)))
(with-selected-window window
(redirect-frame-focus frame last-event-frame))
(display-buffer-record-window 'frame window buffer)
(set-window-dedicated-p window t)
where I used `last-event-frame' because you mentioned it. I'm not
familiar with that variable.
>> > What about other Emacs releases - are relevant at
>> > all in this context?
>> > Should we expect that your code can help them also?
>>
>> If you have an appropriate hook.
>
> Meaning? Is this something I can do (how)?
The above should be applicable to earlier versions to.
> (redirect-frame-focus last-event-frame
> (window-frame (minibuffer-window)))
>
> Is that what you meant?
Not really because I don't understand the semantics of
`last-event-frame' well enough. But if it works, all the better.
> That works, in all Emacs versions, even without your code! And so does using
> this in its place:
>
> (select-frame-set-input-focus
> (window-frame (minibuffer-window)))
>
> (Is there a difference? What is the advantage of either?)
If you do this wrapped in a `with-selected-window' it should do the same
as `redirect-frame-focus'. Otherwise, it will probably bring the frame
into foreground. If `redirect-frame-focus' works, stay with it.
> 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?
> 2. If I type "no," and then I do `C-x k', then even though *Process List* has
> its frame border highlighted as if it is selected, the buffer proposed for
> deletion is *shell*. OK, so I kill *shell*, and confirm ("yes') to kill its
> processes also. (BTW, `C-x k' in my setup also deletes the window/frame.) So
> far, so good.
>
> But if I try to use `C-x k' again to kill *Process List*, then, as soon as I
hit
> the `k':
>
> a. The default buffer to kill is proposed as some other buffer, not *Process
> List* (in my setup the default value is automatically inserted in the
> minibuffer, so I can see it without doing M-n).
>
> b. Emacs crashes, but gives no "fatal error" dialog box - hence no way to
access
> gdb. It just directly shows the MS Windows dialog box for sending an error
> report to MS. When I click yes/no in that dialog box Emacs exits
(disappears).
Could be the abort in delete_frame I've told you about. Why don't you
run Emacs in the debugger jsut from the beginning? (In a running
instance of Emacs go to the src directory, type M-x gdb, give your
full-path emacs.exe as argument, type "run" and do your things until the
emacs fired up this way becomes unresponsive. A "bt full" in the first
instance should tell you what happened.)
> I can repro this systematically, but there seems to be no way to use gdb. If
I
> do something else instead of `C-x k' - e.g. `C-x o', then there is no problem.
> I can, for instance, use `C-x o' to move among frames (`C-x o' moves to the
> other frame in my setup, if there is no other window on the same frame),
coming
> eventually to *Process List*, and then use `C-x k' to kill *Process List*.
>
> This crash is reproducible also with Emacs 23.3, not just with the latest
Emacs
> 24 build. It does not happen with Emacs 22.3, however. Dunno whether this
> crash is related to the crashes you are seeing.
>
> Anyway, it seems we are very close, for my needs. I suppose I can put that
> redirection on `post-command-hook' (instead of in `1on1-fit-minibuffer-frame',
> which some oneonone.el users will not use), and things should generally work.
I
> will try that next.
That's a bad idea in my opinion. Redirect as soon as possible. Why
don't you use `after-make-frame-functions'?
martin
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', (continued)
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/18
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/19
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/19
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/21
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/21
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/18
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/19
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/19
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', martin rudalics, 2012/07/21
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/21
- 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/22
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Eli Zaretskii, 2012/07/22
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/22
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Eli Zaretskii, 2012/07/22
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes', Drew Adams, 2012/07/22
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes', Drew Adams, 2012/07/22
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes', Daniel Colascione, 2012/07/22
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes', Drew Adams, 2012/07/22
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes', Drew Adams, 2012/07/22
- bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus whenit calls `list-processes', Eli Zaretskii, 2012/07/23