bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> > All experienced Emacs users have enable-recursive-minibuffers enabled
> 
> I don't, FWIW.  So please don't build any revolutionary UI changes on
> that wrong assumption.

+1.

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

I don't have a simple recipe, but I doubt that one is needed.  If it
really is then perhaps I will come up with one.

I have some code that calls `y-or-n-p'.  Immediately after it prompts,
`Man-bgproc-sentinel' writes a message to the echo area:

(message "%s man page formatted" (Man-page-from-arguments Man-arguments))

The user thus sees only a message such as "ps man page formatted".
S?he never sees the `y-or-n' prompt.

(Yes, of course as soon as the user tries to hit a key for some reason,
s?he sees the `y-or-n-p' repeat prompt.)

Seems like this is an Emacs bug.  Seems like whenever `y-or-n-p' (or
just `read-key') is waiting for a key, `message' should do nothing.
Either it should echo its message after the key is read or (maybe
better) it should do nothing at all.  As it stands now, this seems like
a basic UI problem, not just a minor annoyance.

FWIW, the context is that I am jumping to a `man' bookmark with code
that can activate the region recorded in the bookmark (not a vanilla
`man' bookmark), and if the region has been relocated (because the
target text has changed) then the user is prompted for whether s?he
wants to save the relocated region limits back to the bookmark.  This
prompting is done by `y-or-n-p'.  But `Man-bgproc-sentinel' then comes
along and overwrites the prompt.

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2014-10-20 on LEG570
Bzr revision: 118168 rgm@gnu.org-20141020195941-icp42t8ttcnud09g
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> AFAIU the issues fixed were all special cases were a message hided some
> y-or-n-p prompt so that the user may have missed the prompt, or may
> have wondered what to do to get it back.

I see.  So the problem is that `y-or-n-p' uses the
echo area for prompting, and `message' writes to
the echo area.  Yes, that's indeed a problem.
Sorry for not understanding that that's what we're
trying to solve.

[I still don't understand why it's said that your
minibuffer input gets permanently hidden, in that
scenario.  I suppose that if the result of your
`y-or-n-p' answer causes Emacs to quit or to kill
stuff then that could happen, but I wouldn't think
it would happen generally.  Your input is in the
minibuffer; the prompt from `y-or-n-p' is in the
echo area.]

> > What I've said is that I object to an automatic
> > attempt to determine, when the minibuffer is
> > active, whether to realize the effect of `message'
> > or the effect of `minibuffer-message'.
> 
> AFAICT only the behavior for these special situations have been made a
> bit more user friendly, and all other calls of message or mb-message
> are uneffected (is that correct, Juri?) so that third party stuff should
> not be affected.

I see.  I hope that's right.  I got the impression
that a change was being made to detect whether the
minibuffer is active, and, when so, make `message'
calls behave instead like `minibuffer-message'.
That would not be good.

Can someone please confirm that that's not the case?

> `y-or-n-p' has been reimplemented to use
> read-from-minibuffer instead of read-key, however.

I see.  That sounds like a big change, just to fix
the "special situations" you described.  And it
sounds bad, to me.

`y-or-n-p' is not the only situation where we prompt
in the echo area and read a key.

If we're really going to make big changes, wouldn't
it be better to do something different, to address
all such read-key situations - aren't they all
potentially problematic (special situations)?

Why would we want to switch such situations to read
from the minibuffer (activating it, prompting in it,
etc.)?

Reading a key (which is what this is about, IIUC)
isn't specific to any particular _input location_
(e.g. the minibuffer).

It can be relevant to the place where that action
gets initiated (to maybe pick up relevant keymaps).
But it shouldn't be associated with any particular
expected-input location.

To read a key, the prompt basically _tells_ the
the user to hit a key.  It's not looking to read
any input into a buffer - minibuffer or otherwise.

Why not instead just put the prompt in a temporary
(unselected) popup window or undecorated frame?

IMO there should be no need to give `y-or-n-p',
or any other function that reads a key,
interaction with the  minibuffer.  Just because
we need to prompt, and be sure the user sees the
prompt, that doesn't imply that we should use the
minibuffer.

No need and no reason to do that, is there?
Using the minibuffer to read a key introduces
unnecessary complexity and confusion for users.
We present an input buffer for no reason - no
text gets edited and input there.

The minibuffer is a heavy-weight UI, allowing
lots of possible interactions.  I have a hard
time believing that, just to solve the problem
you described, we would end up going down this
route.

(A key can be read anytime - whether or not
the minibuffer's active.  And it certainly
shouldn't require a recursive minibuffer if
key-reading is initiated while the minibuffer
is active for something else.)

Using the minibuffer for _output_, as does
`minibuffer-message', is generally worse, not
better, than using the echo area for output
(`message') and reserving the minibuffer for
input only.

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Michael Heerdegen]

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

> [I still don't understand why it's said that your
> minibuffer input gets permanently hidden, in that
> scenario.  I suppose that if the result of your
> `y-or-n-p' answer causes Emacs to quit or to kill
> stuff then that could happen, but I wouldn't think
> it would happen generally.  Your input is in the
> minibuffer; the prompt from `y-or-n-p' is in the
> echo area.]

You misunderstood the word "permanently": We didn't mean you can't get
the y-or-n-p prompt back but that the prompt doesn't come back from
alone without user interaction, no matter how long you wait.

> > AFAICT only the behavior for these special situations have been made a
> > bit more user friendly, and all other calls of message or mb-message
> > are uneffected (is that correct, Juri?) so that third party stuff should
> > not be affected.
>
> I see.  I hope that's right.  I got the impression
> that a change was being made to detect whether the
> minibuffer is active, and, when so, make `message'
> calls behave instead like `minibuffer-message'.
> That would not be good.
>
> Can someone please confirm that that's not the case?

I think Juri did that.


Regards,

Michael.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> > [I still don't understand why it's said that your
> > minibuffer input gets permanently hidden, in that
> > scenario.  I suppose that if the result of your
> > `y-or-n-p' answer causes Emacs to quit or to kill
> > stuff then that could happen, but I wouldn't think
> > it would happen generally.  Your input is in the
> > minibuffer; the prompt from `y-or-n-p' is in the
> > echo area.]
> 
> You misunderstood the word "permanently": We didn't mean you can't get
> the y-or-n-p prompt back but that the prompt doesn't come back from
> alone without user interaction, no matter how long you wait.

The statement made wasn't about the prompt.  It was
about minibuffer input.

My reply was that input is in the minibuffer,
and both `message' and `y-or-n-p' write to the
echo area (or at least they both did), so I
can't imagine how minibuffer input is lost or
"permanently hidden".

> > > AFAICT only the behavior for these special
> > > situations have been made a bit more user
> > > friendly, and all other calls of message or
> > > mb-message are uneffected (is that correct,
> > > Juri?) so that third party stuff should
> > > not be affected.
> >
> > I see.  I hope that's right.  I got the impression
> > that a change was being made to detect whether the
> > minibuffer is active, and, when so, make `message'
> > calls behave instead like `minibuffer-message'.
> > That would not be good.
> >
> > Can someone please confirm that that's not the case?
> 
> I think Juri did that.

I didn't think so - not explicitly.  He confirmed
your "AFAICT only the behavior..." description, but
also your statement that "`y-or-n-p' has been
reimplemented to use read-from-minibuffer instead of
read-key" statement. (Or perhaps just one of those?)

There are mentions in this thread (and others?) of
`minibuffer-message' being used in place of `message'
when the minibuffer is active.  So it's still not
clear to me that such a change is not being made.

And I disagreed that `y-or-n-p' should read from
the minibuffer instead of reading a key.  I guessed
that the problem that that tries to solve should
still exist for all uses of `read-key' that issue
a prompt (which is probably all uses of it).  No?

A general statement that "third party stuff should
not be affected" is great, as far as it goes.  But
I guess I'll just have to wait till Emacs 27 to see
the devil in the details.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Michael Heerdegen]

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

> My reply was that input is in the minibuffer,
> and both `message' and `y-or-n-p' write to the
> echo area (or at least they both did), so I
> can't imagine how minibuffer input is lost or
> "permanently hidden".

Ah, ok.  I think the posters just confused minibuffer and echo area for
the case of y-or-n-p then (at least did I).

> > > Can someone please confirm that that's not the case?
> >
> > I think Juri did that.
>
> I didn't think so - not explicitly.  He confirmed
> your "AFAICT only the behavior..." description, but
> also your statement that "`y-or-n-p' has been
> reimplemented to use read-from-minibuffer instead of
> read-key" statement. (Or perhaps just one of those?)
>
> There are mentions in this thread (and others?) of
> `minibuffer-message' being used in place of `message'
> when the minibuffer is active.

Yes - in the reported situations, not generally...maybe someone could
send Drew an accumulated diff of all changes or so?

> And I disagreed that `y-or-n-p' should read from
> the minibuffer instead of reading a key.

I guess this can be debated - I don't have an opinion so far.


Michael.

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> > My reply was that input is in the minibuffer,
> > and both `message' and `y-or-n-p' write to the
> > echo area (or at least they both did), so I
> > can't imagine how minibuffer input is lost or
> > "permanently hidden".
> 
> Ah, ok.  I think the posters just confused minibuffer and echo area for
> the case of y-or-n-p then (at least did I).

That's easy to do.  But the statement wasn't just
about the minibuffer when echo area was meant, or
vice versa.  The claim was that _user input_ (not
a prompt) became permanently hidden.

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Michael Heerdegen]

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

> > Ah, ok.  I think the posters just confused minibuffer and echo area for
> > the case of y-or-n-p then (at least did I).
>
> That's easy to do.  But the statement wasn't just
> about the minibuffer when echo area was meant, or
> vice versa.  The claim was that _user input_ (not
> a prompt) became permanently hidden.

I don't know if that was also a mistake or really meant like that.

Michael.

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> That's easy to do.  But the statement wasn't just
>> about the minibuffer when echo area was meant, or
>> vice versa.  The claim was that _user input_ (not
>> a prompt) became permanently hidden.
>
> I don't know if that was also a mistake or really meant like that.

This is not a mistake.  Permanently hidden user input
is a serious problem and security threat.

Today I started compilation, then in a Dired buffer
requested files deletion that displayed the prompt:

  Delete D [54 files] (y or n)

But before I had a chance to answer the prompt, compilation finished
and obscured the prompt with this message permanently:

  Compilation finished

So I forgot about what was in the prompt :-(

Since Drew doesn't want to improve safety to cover all such cases,
we need to address these issues one by one, so here is the next patch:

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 5a3386f227..101e294557 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -2265,7 +2265,8 @@ compilation-handle-exit
                  (msg (format "%s %s" mode-name
                               (replace-regexp-in-string "\n?$" ""
                                                         (car status)))))
-             (message "%s" msg)
+             (with-current-buffer (window-buffer (old-selected-window))
+               (minibuffer-message "%s" msg))
              (propertize out-string
                          'help-echo msg
                          'face (if (> exit-status 0)

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> But before I had a chance to answer the prompt, compilation finished
> and obscured the prompt with this message permanently:
>
>   Compilation finished
>
> So I forgot about what was in the prompt :-(

Yeah, it's a problem all over the place.

> Since Drew doesn't want to improve safety to cover all such cases,
> we need to address these issues one by one, so here is the next patch:

Drew doesn't have veto powers.  I say go ahead and make the change in
`message' (with a variable that can be used to force `message' to not
behave like `minibuffer-message').

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> But before I had a chance to answer the prompt, compilation finished
>> and obscured the prompt with this message permanently:
>>
>>   Compilation finished
>>
>> So I forgot about what was in the prompt :-(
>
> Yeah, it's a problem all over the place.
>
>> Since Drew doesn't want to improve safety to cover all such cases,
>> we need to address these issues one by one, so here is the next patch:
>
> Drew doesn't have veto powers.  I say go ahead and make the change in
> `message' (with a variable that can be used to force `message' to not
> behave like `minibuffer-message').

Yes, I believe a new variable would make Drew happy.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

>>> But before I had a chance to answer the prompt, compilation finished
>>> and obscured the prompt with this message permanently:
>>>
>>>   Compilation finished
>>>
>>> So I forgot about what was in the prompt :-(
>>
>> Yeah, it's a problem all over the place.
>>
>>> Since Drew doesn't want to improve safety to cover all such cases,
>>> we need to address these issues one by one, so here is the next patch:
>>
>> Drew doesn't have veto powers.  I say go ahead and make the change in
>> `message' (with a variable that can be used to force `message' to not
>> behave like `minibuffer-message').
>
> Yes, I believe a new variable would make Drew happy.

The variable name is ‘message-in-echo-area’.  After a little testing,
it seems to handle all such cases well:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: message-in-echo-area.patch --]
[-- Type: text/x-diff, Size: 3725 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 6e72eb73f9..7e74fa1ffb 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -712,16 +712,16 @@ minibuffer-message
       (progn
         (if args
             (apply #'message message args)
-          (message "%s" message))
+          (message-in-echo-area "%s" message))
         (prog1 (sit-for (or minibuffer-message-timeout 1000000))
-          (message nil)))
+          (message-in-echo-area nil)))
     ;; Record message in the *Messages* buffer
     (let ((inhibit-message t))
       (if args
           (apply #'message message args)
-        (message "%s" message)))
+        (message-in-echo-area "%s" message)))
     ;; Clear out any old echo-area message to make way for our new thing.
-    (message nil)
+    (message-in-echo-area nil)
     (setq message (if (and (null args)
                            (string-match-p "\\` *\\[.+\\]\\'" message))
                       ;; Make sure we can put-text-property.
diff --git a/src/editfns.c b/src/editfns.c
index 8fc866d391..a1e3fb1fa5 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -2877,6 +2877,49 @@ Fmessage
 
 usage: (message FORMAT-STRING &rest ARGS)  */)
   (ptrdiff_t nargs, Lisp_Object *args)
+{
+  if (NILP (Vmessage_in_echo_area)
+      && !(NILP (args[0]) || (STRINGP (args[0]) && SBYTES (args[0]) == 0))
+      && WINDOW_LIVE_P (Fold_selected_window ())
+      && BUFFERP (Fwindow_buffer (Fold_selected_window ()))
+      && !NILP (Fminibufferp (Fwindow_buffer (Fold_selected_window ()))))
+    {
+      ptrdiff_t count = SPECPDL_INDEX ();
+
+      /* Avoid possible recursion.  */
+      specbind (Qmessage_in_echo_area, Qt);
+
+      record_unwind_current_buffer ();
+      Fset_buffer (Fwindow_buffer (Fold_selected_window ()));
+
+      return unbind_to (count, CALLN (Fapply, intern ("minibuffer-message"),
+                                      Flist (nargs, args)));
+    }
+  else
+    return Fmessage_in_echo_area (nargs, args);
+}
+
+DEFUN ("message-in-echo-area", Fmessage_in_echo_area, Smessage_in_echo_area, 1, MANY, 0,
+       doc: /* Display a message at the bottom of the screen.
+The message also goes into the `*Messages*' buffer, if `message-log-max'
+is non-nil.  (In keyboard macros, that's all it does.)
+Return the message.
+
+In batch mode, the message is printed to the standard error stream,
+followed by a newline.
+
+The first argument is a format control string, and the rest are data
+to be formatted under control of the string.  Percent sign (%), grave
+accent (\\=`) and apostrophe (\\=') are special in the format; see
+`format-message' for details.  To display STRING without special
+treatment, use (message-in-echo-area "%s" STRING).
+
+If the first argument is nil or the empty string, the function clears
+any existing message; this lets the minibuffer contents show.  See
+also `current-message'.
+
+usage: (message-in-echo-area FORMAT-STRING &rest ARGS)  */)
+  (ptrdiff_t nargs, Lisp_Object *args)
 {
   if (NILP (args[0])
       || (STRINGP (args[0])
@@ -4520,6 +4563,11 @@ syms_of_editfns (void)
 it to be non-nil.  */);
   binary_as_unsigned = false;
 
+  DEFVAR_LISP ("message-in-echo-area", Vmessage_in_echo_area,
+	       doc: /* Non-nil means overwrite the minibuffer with a message in the echo area.  */);
+  Vmessage_in_echo_area = Qnil;
+  DEFSYM (Qmessage_in_echo_area, "message-in-echo-area");
+
   defsubr (&Spropertize);
   defsubr (&Schar_equal);
   defsubr (&Sgoto_char);
@@ -4594,6 +4642,7 @@ syms_of_editfns (void)
   defsubr (&Semacs_pid);
   defsubr (&Ssystem_name);
   defsubr (&Smessage);
+  defsubr (&Smessage_in_echo_area);
   defsubr (&Smessage_box);
   defsubr (&Smessage_or_box);
   defsubr (&Scurrent_message);

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> The variable name is ‘message-in-echo-area’.  After a little testing,
> it seems to handle all such cases well:

I have not tested the patch, but it looks good to me.  Tiny comment:

>  usage: (message FORMAT-STRING &rest ARGS)  */)
>    (ptrdiff_t nargs, Lisp_Object *args)
> +{
> +  if (NILP (Vmessage_in_echo_area)

The doc string of `message' (and documentation) should mention this
variable, and this should also be mentioned in NEWS.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

Hello everyone,

I can't confirm 100% if this is the right bug to report this to, but the
recent changes by Juri, which make yes-or-no-p use the minibuffer for
reading,  break fido-mode's icomplete-magic-kill command (apologies if
that's not the exact name).

That command prompts the user for confirmation before attempting a file
deletion or buffer kill. This is done inside the minibuffer.

I haven't followed the whole discussion so I don't know if you're aware of
this problem. Either way, is there an alternative for modes such as
fido-mode?

Thanks,
João

On Tue, Nov 19, 2019, 08:14 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Juri Linkov <juri@linkov.net> writes:
>
> > The variable name is ‘message-in-echo-area’.  After a little testing,
> > it seems to handle all such cases well:
>
> I have not tested the patch, but it looks good to me.  Tiny comment:
>
> >  usage: (message FORMAT-STRING &rest ARGS)  */)
> >    (ptrdiff_t nargs, Lisp_Object *args)
> > +{
> > +  if (NILP (Vmessage_in_echo_area)
>
> The doc string of `message' (and documentation) should mention this
> variable, and this should also be mentioned in NEWS.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2015 bytes --]

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

> I can't confirm 100% if this is the right bug to report this to, but
> the recent changes by Juri, which make yes-or-no-p use the minibuffer
> for reading, break fido-mode's icomplete-magic-kill command
> (apologies if that's not the exact name).

Please provide step-by-step recipe, it's hard to see what is wrong.
I tried everything, and don't see anything unusual.

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[João Távora]

On Tue, Nov 19, 2019 at 11:20 PM Juri Linkov <juri@linkov.net> wrote:
>
> > I can't confirm 100% if this is the right bug to report this to, but
> > the recent changes by Juri, which make yes-or-no-p use the minibuffer
> > for reading, break fido-mode's icomplete-magic-kill command
> > (apologies if that's not the exact name).
>
> Please provide step-by-step recipe, it's hard to see what is wrong.
> I tried everything, and don't see anything unusual.

Sorry Juri, I was reporting from my mobile phone.

An easy recipe:

Emacs -Q
M-x fido-mode
(defalias 'yes-or-no-p 'y-or-n-p) ;; a common custmization
C-x b
C-k ;; to kill the Messages buffer

Before your changes to `y-or-n-p` this worked well, afterwards
I get the "Attempt to use minibuffer inside minibuffer" error.

Bear in mind that fido-mode is very new. Also bear in mind
that the problem is already present when yes-or-no-p is used.

I think a good fix is for icomplete to do this (and for
you to do nothing :-) )

diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 8410ca5c3e..bf1d69a4c5 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -241,6 +241,8 @@ icomplete-fido-kill
              (category (alist-get 'category (cdr md)))
              (all (completion-all-sorted-completions))
              (thing (car all))
+             (enable-recursive-minibuffers t)
+             (icomplete-mode nil)
              (action
               (pcase category
                 (`buffer

WDYT?
João

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

> Emacs -Q
> M-x fido-mode
> (defalias 'yes-or-no-p 'y-or-n-p) ;; a common custmization
> C-x b
> C-k ;; to kill the Messages buffer
>
> Before your changes to `y-or-n-p` this worked well, afterwards
> I get the "Attempt to use minibuffer inside minibuffer" error.
>
> Bear in mind that fido-mode is very new. Also bear in mind
> that the problem is already present when yes-or-no-p is used.
>
> I think a good fix is for icomplete to do this (and for
> you to do nothing :-) )

It's tempting to do nothing :-), but since the problem is
already present with yes-or-no-p too, it should be fixed
because it's a general problem affecting other commands too.

The nil value of enable-recursive-minibuffers by default was intended
to avoid confusion for beginners unadvisedly typing such sequences as
M-x M-x M-x M-x M-x ... to get out from which is not easy.

But for yes/no or y/n questions it should be right to
allow recursive minibuffers temporarily:

diff --git a/lisp/subr.el b/lisp/subr.el
index 20daed623f..2265965c60 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -2847,6 +2848,7 @@ y-or-n-p
      (t
       (setq prompt (funcall padded prompt))
       (let* ((empty-history '())
+             (enable-recursive-minibuffers t)
              (str (read-from-minibuffer
                    prompt nil
                    (make-composed-keymap y-or-n-p-map query-replace-map)
diff --git a/src/fns.c b/src/fns.c
index cbb6879223..3ae3192b3d 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -2805,15 +2805,18 @@ DEFUN ("yes-or-no-p", Fyes_or_no_p, Syes_or_no_p, 1, 1, 0,
   AUTO_STRING (yes_or_no, "(yes or no) ");
   prompt = CALLN (Fconcat, prompt, yes_or_no);
 
+  ptrdiff_t count = SPECPDL_INDEX ();
+  specbind (Qenable_recursive_minibuffers, Qt);
+
   while (1)
     {
       ans = Fdowncase (Fread_from_minibuffer (prompt, Qnil, Qnil, Qnil,
 					      Qyes_or_no_p_history, Qnil,
 					      Qnil));
       if (SCHARS (ans) == 3 && !strcmp (SSDATA (ans), "yes"))
-	return Qt;
+	return unbind_to (count, Qt);
       if (SCHARS (ans) == 2 && !strcmp (SSDATA (ans), "no"))
-	return Qnil;
+	return unbind_to (count, Qnil);
 
       Fding (Qnil);
       Fdiscard_input ();

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[João Távora]

Juri Linkov <juri@linkov.net> writes:

>> Emacs -Q
>> M-x fido-mode
>> (defalias 'yes-or-no-p 'y-or-n-p) ;; a common custmization
>> C-x b
>> C-k ;; to kill the Messages buffer
>>
>> Before your changes to `y-or-n-p` this worked well, afterwards
>> I get the "Attempt to use minibuffer inside minibuffer" error.
>>
>> Bear in mind that fido-mode is very new. Also bear in mind
>> that the problem is already present when yes-or-no-p is used.
>>
>> I think a good fix is for icomplete to do this (and for
>> you to do nothing :-) )
>
> It's tempting to do nothing :-), but since the problem is
> already present with yes-or-no-p too, it should be fixed
> because it's a general problem affecting other commands too.

I tend to agree, but it's a longstanding thing in Emacs, so I would be
very wary of touching it (at least until we get some more opinions).

>
> The nil value of enable-recursive-minibuffers by default was intended
> to avoid confusion for beginners unadvisedly typing such sequences as
> M-x M-x M-x M-x M-x ... to get out from which is not easy.

That may be true, but are you sure there aren't other problems being
avoided by it?

Let me give you and example: in icomplete-mode, there is a
post-command-hook that displays some overlays in the minibuffer.  Now,
if we take your patch, indeed icomplete-mode doesn't have to worry about
enable-recursive-minibuffers in the example I gave you.  This is good,
no more error message.  However, that also means that instead of an
annoying error message, you get another confusing bug where the
post-command-hook will prevail in the recursive minibuffer, which just
doesn't make sense when answering just yes-or-no.

In this particular case, I additionally protected the code against this,
but what I'm saying is that other bugs may be uncovered by your patch
that are today hidden behind the annoying-but-reasonable error message.

João

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> It's tempting to do nothing :-), but since the problem is
>> already present with yes-or-no-p too, it should be fixed
>> because it's a general problem affecting other commands too.
>
> I tend to agree, but it's a longstanding thing in Emacs, so I would be
> very wary of touching it (at least until we get some more opinions).

Many other important minibuffer-reading functions already let-bind
enable-recursive-minibuffers to t:

custom-variable-prompt
find-function-read
describe-function
describe-variable
describe-symbol
read-input-method-name
read-char-by-name
read-passwd
and many other.

So yes-or-no-p could do the same because it's important for users to be
able to answer yes/no questions regardless of whether they activated the
minibuffer intentionally or by mistake.

>> The nil value of enable-recursive-minibuffers by default was intended
>> to avoid confusion for beginners unadvisedly typing such sequences as
>> M-x M-x M-x M-x M-x ... to get out from which is not easy.
>
> That may be true, but are you sure there aren't other problems being
> avoided by it?
>
> Let me give you and example: in icomplete-mode, there is a
> post-command-hook that displays some overlays in the minibuffer.  Now,
> if we take your patch, indeed icomplete-mode doesn't have to worry about
> enable-recursive-minibuffers in the example I gave you.  This is good,
> no more error message.  However, that also means that instead of an
> annoying error message, you get another confusing bug where the
> post-command-hook will prevail in the recursive minibuffer, which just
> doesn't make sense when answering just yes-or-no.
>
> In this particular case, I additionally protected the code against this,
> but what I'm saying is that other bugs may be uncovered by your patch
> that are today hidden behind the annoying-but-reasonable error message.

All experienced Emacs users have enable-recursive-minibuffers enabled,
so everything should work regardless of the value of enable-recursive-minibuffers.

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 21 Nov 2019 23:39:42 +0200
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17272@debbugs.gnu.org,
>  Lars Ingebrigtsen <larsi@gnus.org>, 19064@debbugs.gnu.org
> 
> All experienced Emacs users have enable-recursive-minibuffers enabled

I don't, FWIW.  So please don't build any revolutionary UI changes on
that wrong assumption.

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

> I don't, FWIW.  So please don't build any revolutionary UI changes on
> that wrong assumption.

But do you agree that answering yes/no questions should be allowed anytime
regardless of the value of enable-recursive-minibuffers?

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: joaotavora@gmail.com,  michael_heerdegen@web.de,  17272@debbugs.gnu.org,
>   larsi@gnus.org,  19064@debbugs.gnu.org
> Date: Sat, 23 Nov 2019 21:02:45 +0200
> 
> > I don't, FWIW.  So please don't build any revolutionary UI changes on
> > that wrong assumption.
> 
> But do you agree that answering yes/no questions should be allowed anytime
> regardless of the value of enable-recursive-minibuffers?

Yes, I think so.

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> > I don't, FWIW.  So please don't build any revolutionary UI changes on
>> > that wrong assumption.
>> 
>> But do you agree that answering yes/no questions should be allowed anytime
>> regardless of the value of enable-recursive-minibuffers?
>
> Yes, I think so.

So I installed the patch that allows it.

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> So I installed the patch that allows it.

FWIW and FTR, as the filer of bug #19064,
and as I expressed several times in this
thread, I strongly object to the changes
that have now been made.  All of what I said
has been ignored.  Unfortunate.

This is not at all a good fix for the problem
reported.  And it imposes a very bad behavior
more generally - beyond the problem cited.

`message' and `minibuffer-message', i.e.,
writing to the echo area and to the minibuffer,
both have their uses when the minibuffer is
active.

And `y-or-n-p' should continue to use `read-key',
not the minibuffer.

And `enable-recursive-minibuffers' should not
be turned on automatically by `yes-or-no-p'.
Instead, if the function calling `yes-or-no-p'
has not turned it on then an error should be
raised when `yes-or-no-p' tries to use the
minibuffer.

I'm not aware of any part of this "fix" that's
acceptable.