bug#41087: 27.0.91; How to remove Emacs 27 changes to minibuffer?

[Drew Adams <drew.adams@oracle.com>]

> > 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$
>