GNU bug report logs - #21396
25.0.50; read-key's prompt is not visible

Previous Next

Full log

Message #53 received at 21396 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21396 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#21396: 25.0.50; read-key's prompt is not visible
Date: Fri, 04 Sep 2015 11:27:30 +0200

Eli Zaretskii <eliz <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.