Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin and Eli.

On Thu, Mar 18, 2021 at 16:51:32 +0100, martin rudalics wrote:
>  >> The problem that Miha highlighted is that when there is an open
>  >> minibuffer when that last frame is deleted, that open minibuffer remains
>  >> in existence, fouling up the next emacsclient session.
>  >>
>  >> Maybe such open minibuffers should just be aborted (along with any other
>  >> recursive edits) when the last frame gets deleted.  This would be
>  >> simpler to code than preserving those minibuffers somewhere, and
>  >> restoring them at the next emacsclient session.  Aborting them also
>  >> seems more natural, since their contents are unlikely to have any
>  >> relevance to the next emacsclient session.
>  >
>  > Martin, can you comment on this, please?

> What about answering questions about unsaved buffers, running processes
> ...  in such a situation?  I never use emacsclient so I have no idea how
> this should behave in practice.

I don't use emacsclient either.  But questions about unsaved buffers
seem to prevent Emacs terminating until they get answered.  The same for
running processes (at least, for gdb).

> But any non-crucial dialog should be aborted IMHO.

Are the any uses of the minibuffer which count as crucial, in this
sense?

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).