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

["Drew Adams" <drew.adams@oracle.com>]

>  > The frame for posing and answering all questions should 
>  > be, as usual, the minibuffer frame.  Aside from `read-event'
>  > etc., reading user input should use the minibuffer, and that
>  > means it should use the minibuffer frame....
>  >
>  > It makes no sense for any other frame to have the input 
>  > focus when reading from the minibuffer, since no other frame
>  > _has_ a minibuffer.
> 
> Most users don't care about standalone minibuffer frames.  
> They want to see one frame where they find all information.

This bug is about those users who _do_ use a standalone minibuffer frame,
whether they are a majority or a minority of GNU Emacs users.  They want reading
of user input and echoing of messages to take place in the same location each
time: the standalone minibuffer frame.  I'm confident of that, even if it is
presumptuous to speak of what other users might want.

FWIW, if most GNU Emacs users do not use a standalone minibuffer today, it might
have something to do with bugs like this one.  I'd be willing to bet that at
least half the users of Epoch did use the standalone minibuffer.  But in Epoch
it was standard, available out of the box, and worked perfectly.  IOW, Epoch
users had a real, simple choice, with no jumping through hoops.

Using a standalone minibuffer is not some oddball idea, even if only a minority
of users choose it today.  And even if, after the bugs are fixed in GNU Emacs,
such users remain a minority, that does not mean that their use case is
unimportant.

>  >>  > But in the case of a standalone minibuffer, it definitely
>  >>  > should continue to have the input focus.
>  >>
>  >> Why "continue"?  You could invoke C-x C-c in any frame.
>  >
>  > See above.  It should have the input focus for any _reading
>  > from the minibuffer_.  Obviously, other frames can have the input 
>  > focus when not reading from the minibuffer.  `yes-or-no-p' reads
>  > from the minibuffer.
> 
> So if another frame has input focus and emacs asks a `yes-or-no-p'
> question, focus _should_ switch.

Emacs should always switch to the minibuffer when it reads from the minibuffer,
yes.  You cannot use the minibuffer if it does not have the focus.  And that's
the point of this bug.

>  > But the behavior I saw with that test indicated/suggested 
>  > that *Help* was not entirely special-display...
>  >
>  > The frame was created with the correct colors etc., but 
>  > buffer *Help* ended up being replaced in the frame, which is not
>  > what "special display" means.  So I think there might be a
>  > second bug here.
> 
> If this is independent from the behavior we discuss currently, we'll
> have to investigate it.

I'm comforted that you consider that behavior to be a bug.  See also my earlier
message today, where I reported (seemingly) the same bug wrt special-display
buffer `*Process List*' when testing the code you sent.  That special-display
definition was made differently (via `special-display-regexps'), but the bugged
effect seems to be the same.

No buffer should take the place of a special-display buffer in its window/frame.
That's always been part of the definition of "special display".

>  >>  > If I use Dired+ (which does what my patch does) then there
>  >>  > is no problem, so in my daily use this is solved for the
>  >>  > Dired but reported, but not in general (viz.
>  >>  > this bug wrt quitting with active processes).
>  >>
>  >> But your patch doesn't address the input focus issue or 
>  >> am I missing something?
>  >
>  > Correct.  But the problem does not exist with my patch.  I 
>  > don't have an explanation.
> 
> Me neither.  You would have to go through it and find what it does
> differently.
> 
>  > But please see the #15566 thread

Sorry, I meant #11566.

Note: I am testing using 24.1.  Dunno whether the bug reported in #11566 was
deemed to have been fixed after 24.1 or before it.  IOW, perhaps it has been
fixed since 24.1, but I cannot test with a recent build until I can get a post
24.1 Windows build that works.