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

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

[Drew Adams]

NEWS says this:

** Minibuffer

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

+++
*** 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.

---
*** Minibuffer now uses 'minibuffer-message' to display error messages
at the end of the active minibuffer.

+++
*** 'y-or-n-p' now uses the minibuffer to read 'y' or 'n' answer.

---
*** Some commands that previously used 'read-char-choice' now read
a character using the minibuffer by 'read-char-from-minibuffer'.


Emacs 27 is unfortunately _totally_ unusable for me.  Cannot do the
slightest thing.

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?



In GNU Emacs 27.0.91 (build 1, x86_64-w64-mingw32)
 of 2020-04-20
Repository revision: c36c5a3dedbb2e0349be1b6c3b7567ea7b594f1c
Windowing system distributor `Microsoft Corp.', version 10.0.18362
Configured using:
 `configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

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

[Eli Zaretskii]

> Date: Mon, 4 May 2020 14:07:59 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> Emacs 27 is unfortunately _totally_ unusable for me.  Cannot do the
> slightest thing.

Please provide at least some examples of the difficulties.  It's hard
to say anything intelligent without that much.

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

The NEWS mentions a few variables that should allow you to do that,
but without knowing what you want to undo, it is hard to say more.

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

[Drew Adams]

> > Emacs 27 is unfortunately _totally_ unusable for me.  Cannot do the
> > slightest thing.
> 
> Please provide at least some examples of the difficulties.  It's hard
> to say anything intelligent without that much.

I can't at this point.  I simply can't use it at all.
It will take a very long time, I expect, to figure
anything out about it.  I spent quite a while in the
Lisp debugger today, and didn't scratch the surface.

I don't have time for this now, I'm afraid.  I'll
have to hope that others encounter problems that are
related and later I'll perhaps get a pretest candidate
that I can use to further find out what's wrong.

If no one else runs into related problems then I'll
have to get into it at some point, no doubt.  But
I likely won't have the time to do that for quite
a while.  I don't want this to be the end of my use
of Emacs (e.g. staying forever with 26.3), but that
might need to be the case.

> > I think that some of the problems come from the changes to minibuffer
> > and echo-area behavior.

I really don't know that, so ignore that thought.
I do want to undo such changes, but I don't have
a clue whether they might be causing deeper problems.

> > 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?
> 
> The NEWS mentions a few variables that should allow you to do that,
> but without knowing what you want to undo, it is hard to say more.

I didn't notice such variables.  Anyway, I'll worry
about that later, and just assume for now that it's
not at the root of the bigger problems I have.

But yes, I don't want minibuffer-message replacing
messge whenever the minibuffer is active, etc.  I
want the echo area as it was and minibuffer-message
and message as they were.

I realize that this bug report doesn't help anything
at this point.  I guess the message for now is that
my Emacs is completely broken - can't even begin to
use it for anything.  In particular, my *Completions*
buffer is shown in a separate frame, whose focus is
redirected to the minibuffer.  That's essentially
broken now.

There seems to be some additional handle-switch-frame,
which breaks that relation somehow (?), so typing in
the minibuffer, and then hitting TAB, which pops up
the *Completions* frame, takes input focus away from
the minibuffer frame (and gives it to the *Completions*
frame, which is read-only).

My setup works with each Emacs release, from 20 to 26.

I know this is all very vague.  Sorry.

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

[Eli Zaretskii]

> Date: Mon, 4 May 2020 21:35:05 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 41087@debbugs.gnu.org
> 
> > > Emacs 27 is unfortunately _totally_ unusable for me.  Cannot do the
> > > slightest thing.
> > 
> > Please provide at least some examples of the difficulties.  It's hard
> > to say anything intelligent without that much.
> 
> I can't at this point.  I simply can't use it at all.
> It will take a very long time, I expect, to figure
> anything out about it.  I spent quite a while in the
> Lisp debugger today, and didn't scratch the surface.

Well, hopefully you will be able to tell more at some point.
Otherwise we cannot do anything with this bug report.


> But yes, I don't want minibuffer-message replacing
> messge whenever the minibuffer is active, etc.  I
> want the echo area as it was and minibuffer-message
> and message as they were.

These two sentences seem to contradict each other.  The first says
that you want the new feature in Emacs 27, the second says that you
don't want it.

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

[Noam Postavsky]

Drew Adams <drew.adams@oracle.com> writes:

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

> ** Minibuffer
>
> +++
> *** 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).

> +++
> *** 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.

(setq set-message-function nil)
(setq clear-message-function nil)

[485b423e8f0]: 2019-12-22 00:02:10 +0200
  New variable set-message-function to show message at the end of the minibuffer
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=485b423e8f0df2711a850be7f254665f64ab0bdb

> ---
> *** Minibuffer now uses 'minibuffer-message' to display error messages
> at the end of the active minibuffer.

(remove-hook 'minibuffer-setup-hook 'minibuffer-error-initialize)

[2aae0630552]: 2019-06-03 23:27:19 +0300
  User-friendly display of error messages at the end of minibuffer
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=2aae063055283ee64ecf339c812a1fe6d1cb106e>

> +++
> *** '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://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a26a8cc1c85f29fb11209c16d53a8ae4e4ab7ced

> ---
> *** 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://git.savannah.gnu.org/cgit/emacs.git/commit/?id=027f218ad227c3966df94b22566c2e89a307362d

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

[Drew Adams]

> > But yes, I don't want minibuffer-message replacing
> > message whenever the minibuffer is active, etc.  I
> > want the echo area as it was and minibuffer-message
> > and message as they were.
> 
> These two sentences seem to contradict each other.  The first says
> that you want the new feature in Emacs 27, the second says that you
> don't want it.

No, they both say I don't want it.  I want the previous
behavior, not the new behavior.  No automatic conversion
of `message' to `minibuffer-message' just because the
minibuffer is active [1st sentence].  Echo area as it
was before, minibuffer as it was before, `message' and
`minibuffer-message' as they were before [2nd sentence].

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

[Drew Adams]

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

[Juri Linkov]

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

There are a lot of such preprocessing lines in your libraries

  (< emacs-major-version 23)
  (= emacs-major-version 24)

so you could add something like

  (>= emacs-major-version 27)

to handle changes in Emacs 27.

Since NEWS describes how to get back a previous behavior,
I'm closing this report.

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

[Drew Adams]

> > 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.
> 
> There are a lot of such preprocessing lines in your libraries
> 
>   (< emacs-major-version 23)
>   (= emacs-major-version 24)
> 
> so you could add something like
> 
>   (>= emacs-major-version 27)
> 
> to handle changes in Emacs 27.
> 
> Since NEWS describes how to get back a previous behavior,
> I'm closing this report.

I'm not interested in excluding Emacs 27 from all
my libraries.

1. I'm interested in being able to use Emacs 27 myself,
which is impossible now, because of (at least) the
loss of frame focus problem - the main reason I
filed the bug.

2. No, NEWS does not describe anything about this.
It may describe how to reverse some of the other
changes I mentioned - the ones Eli spoke to.

Answers to those other problems, which I'm guessing
is what you're referring to, do not respond to this
bug - which shouldn't be closed.

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

[Drew Adams]

> 2. No, NEWS does not describe anything about this.
> It may describe how to reverse some of the other
> changes I mentioned - the ones Eli spoke to.
                                 ^^^
                                 Noam

> Answers to those other problems, which I'm guessing
> is what you're referring to, do not respond to this
> bug - which shouldn't be closed.

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

[Eli Zaretskii]

> Date: Tue, 12 May 2020 16:56:48 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 41087-done@debbugs.gnu.org
> 
> 2. No, NEWS does not describe anything about this.

You are looking at a stale version of NEWS.

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

[Drew Adams]

> > 2. No, NEWS does not describe anything about this.
> 
> You are looking at a stale version of NEWS.

All I have is the pretest.  By "this" I was referring
to the problems I have with loss of minibuffer-frame
focus (as opposed to the minibuffer-message etc. stuff
of #1).

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

[Eli Zaretskii]

> Date: Tue, 12 May 2020 19:36:39 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: juri@linkov.net, 41087@debbugs.gnu.org
> 
> > > 2. No, NEWS does not describe anything about this.
> > 
> > You are looking at a stale version of NEWS.
> 
> All I have is the pretest.

The current version in Git is easily accessible via Savannah, I recall
showing you the way several times.

> By "this" I was referring to the problems I have with loss of
> minibuffer-frame focus (as opposed to the minibuffer-message
> etc. stuff of #1).

Since you couldn't produce a reasonably detailed description of
"this", I see no way to make any progress here.  You can always reopen
a bug if you later have the details that would help us diagnose and
fix it.