From: Tassilo Horn <tsdh@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 21396@debbugs.gnu.org
Subject: bug#21396: 25.0.50; read-key's prompt is not visible
Date: Fri, 04 Sep 2015 11:27:30 +0200 [thread overview]
Message-ID: <87vbbq356l.fsf@gnu.org> (raw)
In-Reply-To: <831teea8ah.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 04 Sep 2015 11:38:30 +0300")
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
next prev parent reply other threads:[~2015-09-04 9:27 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-02 20:14 bug#21403: 25.0.50; invisible y-or-n-p prompt Mark Oteiza
2015-09-03 20:03 ` Stefan Monnier
2015-09-02 6:16 ` bug#21396: 25.0.50; read-key's prompt is not visible Tassilo Horn
2015-09-03 15:12 ` Stefan Monnier
2015-09-03 17:50 ` Tassilo Horn
2015-09-03 18:03 ` Eli Zaretskii
2015-09-03 18:36 ` Tassilo Horn
2015-09-03 18:18 ` Eli Zaretskii
2015-09-03 18:42 ` Tassilo Horn
2015-09-04 6:38 ` Eli Zaretskii
2015-09-04 8:04 ` Tassilo Horn
2015-09-04 8:38 ` Eli Zaretskii
2015-09-04 9:27 ` Tassilo Horn [this message]
2015-09-03 20:10 ` Stefan Monnier
2015-09-03 20:12 ` Dmitry Gutov
[not found] ` <<87egifgzog.fsf@gnu.org>
[not found] ` <<83d1xz9xjz.fsf@gnu.org>
2015-09-03 18:27 ` Drew Adams
[not found] ` <handler.21396.D21403.144131058918410.notifdone@debbugs.gnu.org>
2015-09-03 20:07 ` bug#21396: closed (Re: bug#21403: 25.0.50; invisible y-or-n-p prompt) Tassilo Horn
2015-09-03 23:02 ` bug#21403: 25.0.50; invisible y-or-n-p prompt Mark Oteiza
2015-09-07 17:17 ` Stefan Monnier
2015-09-07 17:28 ` Stefan Monnier
2015-09-07 1:04 ` Chris Feng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vbbq356l.fsf@gnu.org \
--to=tsdh@gnu.org \
--cc=21396@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.