Re: Stop frames stealing eachothers' minibuffers!

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> The problem I'm trying to solve here is to understand what happens when
>> emacsclient opens a frame on a different terminal from where emacs
>> --daemon was started, when there are active minibuffers on the original
>> terminal.  What would be nice would be for these minibuffers to be moved
>> onto the new frame (when minibuffer-follows-selected-frame is t) or left
>> on the other non-initial frame (otherwise).  It appears, from Miha's
>> observation yesterday, that any active minibuffers would get aborted in
>> this case, to prevent the old frame blocking the new one.
>
> And what's wrong with aborting the active minibuffer in this case?
> isn't that what the user wants?

I see two use cases here.  

1) I've purposefully killed that last active frame.  In this case any
   remaining open minibuffers are probably a mistake.

2) My connection to a remote machine went down, taking my last frame
   with it.  I reconnect and I might want my minibuffer state back.

I'm personally of the opinion that just aborting the minibuffers is good
enough.  Minibuffers should not generally be long-lived with state
anyway.  Under almost all circumstances, I believe any lost minibuffer
state should be recoverable manually.

-- 
Michael Welsh Duggan
(md5i@md5i.com)