bug#21396: 25.0.50; read-key's prompt is not visible

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Redefining functions is the worst of all customization possibilities,
>> of course, but what is the reason that the above cannot be expected
>> to continue working?
>
> Supporting this is maintenance burden that we shouldn't be expected to
> sustain.  When I'm working on extending a function, how am I supposed
> to know that it's defaliased by someone?  If I need to extend the
> function to make it incompatible with these tricks, it's a legitimate
> development that shouldn't be avoided for fear of breaking someone's
> fset.

You cannot and should not!  I am fully aware that I won't benefit from
your extensions to `yes-or-no-p' when I do the above fset.  But for a
function with no side-effects and such a sharp contract as "ask the user
for confirmation and return non-nil if she's fine", I don't see a
practical problem anyway.

Again, the current issue was that `read-key' (and therefore `y-or-n-p')
didn't show its prompt anymore.  That was a real regression, not a
change which had the side-effect of breaking the fset "trick."  Stefan
fixed it not in order to restore compatibility with tricks but because
`read-key' didn't satisfy the contract of its docstring anymore.

> If people keep using such "customizations", it's a clear sign that
> some defcustom or another similar facility is missing, or that the
> original code needs improvement.  So when such situations happen,
> let's report them to the bug tracker, and let's handle them as we
> usually do.

I'm all in favour of having a `user-confirmation-function', and/or a
more sensible use of `yes-or-no-p'/`y-or-n-p' inside emacs (use the
former only when the consequences of a wrong answer are really severe),
or something else.  The problem is that it'll take long until all emacs
packages follow suit, and frequently having to type 2 or 3 chars + RET
instead of just one is something which is cumbersome enough to me and
many others as it seems.

Bye,
Tassilo