Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings]

> > The old behavior is indeed valuable, if only because it is an old 
> > behavior. Emacs' stability is important.  I don't see why the burden of 
> > proof that a behavior about which virtually no Emacs user in the last 
> > twenty years complained is not a bad one would be on me.
>
>    M-x lisp-date-mode RET
>
> signaled an error in all Emacsen until now. Yet no user complained about 
> it over all these years. Should we add a config var so users can get 
> back the old behavior?

I think you meant "lisp-data-mode".  I'm not sure you are teasing me, so:

(1) The "[No match]" error in earlier Emacsen is clear, there is no reason 
a user would have complained about it.

(2) The likelihood that a user tries to type M-x lisp-data-mode RET when 
no such mode exists is very, very low compared to the likelihood that a 
user interacts with the minibuffer.  Admittedly the scenario that is being 
discussed here is more precise than "interacting with the minibuffer", but 
I did experience the old behavior several times without ever thinking it 
was a bug, and found it perfectly coherent.  And I never tried to type M-x 
lisp-data-mode RET.

(3) The old behavior is in this case very easy to get back AFAICS: (fset 
'lisp-data-mode nil).