all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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





  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.