bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focus when it calls `list-processes'

[martin rudalics]

>>  > 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