unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Tino Calancha <tino.calancha@gmail.com>, Eli Zaretskii <eliz@gnu.org>
Cc: 28525@debbugs.gnu.org, npostavs@users.sourceforge.net
Subject: bug#28525: 26.0.60; dired-delete-file: Accept y/n if yes-or-no-p is aliased to y-or-n-p
Date: Sun, 1 Oct 2017 16:15:56 -0700 (PDT)	[thread overview]
Message-ID: <3440084b-1e2d-44d8-a291-44d6622bbbbc@default> (raw)
In-Reply-To: <87poa7tstz.fsf@gmail.com>

FWIW: I don't think that Emacs should test for
function aliases and change its behavior accordingly.

I don't think users should be encouraged to alias
`yes-or-no-p' to `y-or-n-p'.  That's a bad idea
_in general_, IMO, even if it some users might
find it's appropriate for them.

I think that making Emacs code automatically
recognize such an alias just encourages such
(bad) practice on the part of users.

----

FWIW2: It can, however, be helpful to let users
override a design choice of `y-or-n-p' or
`yes-or-no-p' _for a given calling function_
(as opposed to globally).  I've written library
Yes-No, to provide such a feature.

https://www.emacswiki.org/emacs/Yes-No

`yes-no.el' provides no behavior change, except for
code that wants to let users decide.  For that, the
author just provides the symbol for the calling
function as an additional argument to the prompting
function.

For example, the behavior of this call from function
`foo' is unchanged: (yes-or-no-p "Agree? ").

But this call from function `foo' lets users decide:
(yes-or-no-p "Agree? " 'foo).

In the latter case, a user can answer `yes', `no',
or `use-y-or-n' (which is available with completion).
If the latter then the call immediately switches to
using `y-or-n-p', and all `yes-or-no-p' calls from
function `foo' from then on are redirected to use
`y-or-n-p' instead.

Similarly, this call from `bar' lets users decide:
(y-or-n-p "Agree? " 'bar).

Here, a user can answer using character `y', `n',
or `e'.  Answer `e' switches immediately to using
`yes-or-no-p', and all `y-or-n-p' calls from
function `bar' from then on are redirected to
`yes-or-no-p'.

When either redirection is in effect, a user can
of course redirect back again, to the original
behavior (programmer-defined).

And when either redirection is in effect, a user
can reset the call to use only the default behavior
from then on.

To reset a `yes-or-no-p' prompt (redirected from
`y-or-n-p') a user chooses input `reset-to-default'
(with completion).  To reset a `y-or-n-p' prompt
(redirected from `yes-or-no-p') a user uses character
`^'.

A user option lets a user turn off respect of the
optional CALLER arg.  If nil then there is no change
in behavior from vanilla Emacs: no other inputs are
allowed besides yes/no or y/n.  So even if a library
author provides CALLER, to let users decide on a
case-by-case basis, a user can choose not to allow
herself to do so.

(Obviously, a library that uses argument CALLER
must require library `yes-no.el'.)

The behavior is implemented by putting the symbol
for the prompting function to redirect to on the
symbol for the calling function, as the value of
property `yes/no-prompting'.  For example, if a
user chooses `use-y-or-n' from `yes-or-no-p'
called from `foo', we do this to redirect such
calls to prompt with `y-or-n-p':

(put 'foo 'yes/no-prompting 'y-or-n-p)

Resetting to the default behavior just puts
nil as the property value.





  reply	other threads:[~2017-10-01 23:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-20  9:51 bug#28525: 26.0.60; dired-delete-file: Accept y/n if yes-or-no-p is aliased to y-or-n-p Tino Calancha
2017-09-21  8:15 ` Eli Zaretskii
2017-09-30 13:00   ` Tino Calancha
2017-10-01  4:06     ` Tino Calancha
2017-10-01 23:15       ` Drew Adams [this message]
2017-10-02  5:40         ` Tino Calancha
2017-10-02 13:33           ` Drew Adams
2017-10-03  8:02             ` Tino Calancha
2017-10-02 17:41       ` Eli Zaretskii
2017-10-03  8:00         ` Tino Calancha
2017-10-03 11:10           ` Michael Heerdegen

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3440084b-1e2d-44d8-a291-44d6622bbbbc@default \
    --to=drew.adams@oracle.com \
    --cc=28525@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=npostavs@users.sourceforge.net \
    --cc=tino.calancha@gmail.com \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).