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