[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer?
From: |
Drew Adams |
Subject: |
bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer? |
Date: |
Tue, 5 May 2020 11:10:39 -0700 (PDT) |
> > I think that some of the problems come from the changes to minibuffer
> > and echo-area behavior. Regardless of whether that is the case, I
> > want to undo those changes. Is there an option for that? (I hope so.)
> > If not, what changes do I need to make from Lisp, to get back the prior
> > behavior?
>
> Here's my guesses (none tested) about each item you list. Of course,
> these particular may or may not be the cause of your troubles (whatever
> they are).
Thanks, Noam, for going to all the trouble you did.
I'll try them, at least once I get past the main
problem of minibuffer input-focus loss.
> > *** A new user option, 'minibuffer-beginning-of-buffer-movement', has
> > been introduced to allow controlling how the 'M-<' command works in
> > the minibuffer. If non-nil, point will move to the end of the prompt
> > (if point is after the end of the prompt).
>
> AFAICT, this one is already disabled by default (i.e.,
> minibuffer-beginning-of-buffer-movement is nil by default).
I doubt that's related. But OK.
BTW, why a user option for that? Why not just bind
`M-<' to a different command in the minibuffer maps?
(Doesn't matter to me. Just wondering.)
> > *** When the minibuffer is active, echo-area messages are displayed
> > at the end of the minibuffer instead of hiding the minibuffer by the
> > echo area display. The new user option 'minibuffer-message-clear-timeout'
> > controls how messages displayed in this situation are removed from
> > the minibuffer.
I saw that. I'll take a closer look, but a priori
I'm not interested in controlling _HOW_ msgs are
displayed in this situation (the situation being
that they're shown automatically, at the end of the
minibuffer). I'm interested in not having that
situation at all - not how they're displayed at the
end of the minibuffer but how to not have that
happen at all. I want the old behavior (since
Emacs Day One).
> (setq set-message-function nil)
> (setq clear-message-function nil)
Thanks; that's probably it. If it is, I think
NEWS should say explicitly that setting these
to nil removes the new behavior of "When the
minibuffer is active, echo-area messages are ...".
That is, section "** Minibuffer" should tell you
how to revert to the previous Emacs behavior.
In particular, where it says this:
"Minibuffer now uses 'minibuffer-message' to display
error messages at the end of the active minibuffer."
it should tell you how to disable that new behavior.
(And isn't it about all echo-area messages, not just
"error messages"?)
> New variable set-message-function to show message at the end of the
> minibuffer
>
> https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git
> /commit/?id=485b423e8f0df2711a850be7f254665f64ab0bdb__;!!GqivPVa7Brio!L
> G_VudrPxJ8CU6VhuvBVOW0-LlUGAuEG9l125HX6QQ9ReoJg1Gg3NCe430S9TyOY$
Great; thanks. It would be good for the NEWS mention
of that variable to link to the manual explanation.
> > *** Minibuffer now uses 'minibuffer-message' to display error
> > messages at the end of the active minibuffer.
>
> (remove-hook 'minibuffer-setup-hook 'minibuffer-error-initialize)
Good. Pity there's not a simple user option to revert
the new behavior. And it would be good for NEWS to
explicitly show all such code for reverting this
echo-area msgs change in one place.
> User-friendly display of error messages at the end of minibuffer
>
> https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git
> /commit/?id=2aae063055283ee64ecf339c812a1fe6d1cb106e__;!!GqivPVa7Brio!L
> G_VudrPxJ8CU6VhuvBVOW0-LlUGAuEG9l125HX6QQ9ReoJg1Gg3NCe43zpNUlIi$
Thanks. I do recall lots of traffic in the bug list
about Juri's proposed changes. I expressed my
disagreement in detail at the time, to no avail.
But if it's easy enough to revert them all then
that's great, and all one can ask for, I guess.
I do think the doc, and NEWS, could help by
clearly saying how to revert the changes. Maybe
it does so sufficiently; I haven't studied it.
>
>
> > +++
> > *** 'y-or-n-p' now uses the minibuffer to read 'y' or 'n' answer.
>
> You'd have to evaluate the old lisp code of y-or-n-p.
>
> [a26a8cc1c85]: 2019-11-10 00:04:13 +0200
> 'y-or-n-p' now uses the minibuffer to read 'y' or 'n' answer
> (bug#38076)
>
> https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git
> /commit/?id=a26a8cc1c85f29fb11209c16d53a8ae4e4ab7ced__;!!GqivPVa7Brio!L
> G_VudrPxJ8CU6VhuvBVOW0-LlUGAuEG9l125HX6QQ9ReoJg1Gg3NCe438q6MbCM$
>
> > ---
> > *** Some commands that previously used 'read-char-choice' now read
> > a character using the minibuffer by 'read-char-from-minibuffer'.
>
> You'd have to evaluate the old lisp of files--ask-user-about-large-file
> and hack-local-variables-confirm.
>
> [027f218ad22]: 2019-11-10 00:32:09 +0200
> hack-local-variables-confirm uses the minibuffer to read answer
> (bug#38076)
>
> https://urldefense.com/v3/__https://git.savannah.gnu.org/cgit/emacs.git
> /commit/?id=027f218ad227c3966df94b22566c2e89a307362d__;!!GqivPVa7Brio!L
> G_VudrPxJ8CU6VhuvBVOW0-LlUGAuEG9l125HX6QQ9ReoJg1Gg3NCe436x220-7$
>
- bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer?, Drew Adams, 2020/05/04
- bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer?, Noam Postavsky, 2020/05/05
- bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer?,
Drew Adams <=
- bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer?, Juri Linkov, 2020/05/12
- bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer?, Drew Adams, 2020/05/12
- bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer?, Drew Adams, 2020/05/12
- bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer?, Eli Zaretskii, 2020/05/12
- bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer?, Drew Adams, 2020/05/12
- bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer?, Eli Zaretskii, 2020/05/13