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

[martin rudalics <rudalics@gmx.at>]

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