[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stop frames stealing eachothers' minibuffers!

From: Gregory Heytings
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Wed, 06 Jan 2021 09:40:36 +0000
User-agent: Alpine 2.22 (NEB 394 2020-01-19)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]