yes-or-no-p prompt conditionally broken in master?

yes-or-no-p prompt conditionally broken in master?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]

Hi all,

I tend to keep my e
​​
macs build updated with the master every few days.

My last build was 2 days back at this commit:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a3c31adea4970b8a7fc7f495e6a6a6d4a93e69ce
and
everything worked fine.

PROBLEM:
- When on latest master, for ANY yes-or-no-p prompt, for the first prompt I
cannot see the prompt question. At times, all I see is the cursor at the
very left in the minibuffer. At times, I see no cursor and have to assume
that the minibuffer is in focus. I blindly need to hit y or n to proceed
(for example when quitting emacs). Some times, 2nd prompt onwards the
prompt questions start appearing fine.
- This issue goes away if I revert to the above linked commit with my emacs
config.
- This issue also goes away in an emacs -Q session while on the latest
commit on master.

Below are all the commits after that commit that works for me.
So some package I have installed is clashing with one of the below commits.

I tried debugging but cannot narrow down to the problem. Can one of the
authors would know if their commit could have possibly changed how
yes-or-know-p prompt display behaved? A proper direction will help me debug
the problem faster.

| Dmitry Gutov    | vc-git-mode-line-string: Explicitly re-apply the
faceHEADmaster  |
| Paul Eggert     | Treat initial-scratch-message as a doc string
         |
| Paul Eggert     | Fix describe-char bug with glyphs on terminals
          |
| Paul Eggert     | Follow text-quoting-style in display table init
         |
| K. Handa        | Fix typo
          |
| K. Handa        | Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs
          |
| K. Handa        | fix previous change
         |
| David Caldwell  | * lisp/vc/vc-hooks.el (vc-refresh-state): New command
         |
| Paul Eggert     | Escape ` and ' in doc
         |
| Stefan Monnier  | Generalize the prefix-command machinery of C-u
          |
| Paul Eggert     | Rework quoting in tutorial
          |
| Paul Eggert     | Setup quote display only if interactive
         |
| Katsumi Yamaoka | Use defalias at the top level
         |
| Paul Eggert     | terminal-init-w32console mimicks command-line
         |
| Paul Eggert     | Display replacement quotes with shadow glyphs
         |
| Michael Albinus | * lisp/net/tramp-sh.el (tramp-methods) <sudo>: Mask
"Password:". |

PS: One of the packages I have installed is
http://elpa.gnu.org/packages/minibuffer-line.html and I thought that that
might be causing the problem. But disabling that did not fix this.

[-- Attachment #2: Type: text/html, Size: 4362 bytes --]

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 03 Sep 2015 16:31:23 +0000
> 
> - When on latest master, for ANY yes-or-no-p prompt, for the first prompt I
> cannot see the prompt question. At times, all I see is the cursor at the very
> left in the minibuffer. At times, I see no cursor and have to assume that the
> minibuffer is in focus. I blindly need to hit y or n to proceed (for example
> when quitting emacs). Some times, 2nd prompt onwards the prompt questions start
> appearing fine.

FWIW, I cannot reproduce this with the current master.

Re: yes-or-no-p prompt conditionally broken in master?

[Artur Malabarba]

2015-09-03 17:39 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:
>> From: Kaushal Modi <kaushal.modi@gmail.com>
>> Date: Thu, 03 Sep 2015 16:31:23 +0000
>>
>> - When on latest master, for ANY yes-or-no-p prompt, for the first prompt I
>> cannot see the prompt question. At times, all I see is the cursor at the very
>> left in the minibuffer. At times, I see no cursor and have to assume that the
>> minibuffer is in focus. I blindly need to hit y or n to proceed (for example
>> when quitting emacs). Some times, 2nd prompt onwards the prompt questions start
>> appearing fine.
>
> FWIW, I cannot reproduce this with the current master.

I was getting this problem for every single prompt yesterday, but then
I restarted and haven't seen it again since.
So I can confirm something seems to be wrong, just don't know what.

Re: yes-or-no-p prompt conditionally broken in master?

[Dmitry Gutov]

On 09/03/2015 08:22 PM, Artur Malabarba wrote:

> I was getting this problem for every single prompt yesterday, but then
> I restarted and haven't seen it again since.
> So I can confirm something seems to be wrong, just don't know what.

I've just seen this when trying to quit Ediff (M-x vc-ediff (in a file 
with modifications), then `q' -> not prompt).

To reproduce,

(defalias 'yes-or-no-p 'y-or-n-p)

Re: yes-or-no-p prompt conditionally broken in master?

[Tassilo Horn]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 09/03/2015 08:22 PM, Artur Malabarba wrote:
>
>> I was getting this problem for every single prompt yesterday, but then
>> I restarted and haven't seen it again since.
>> So I can confirm something seems to be wrong, just don't know what.
>
> I've just seen this when trying to quit Ediff (M-x vc-ediff (in a file with
> modifications), then `q' -> not prompt).
>
> To reproduce,
>
> (defalias 'yes-or-no-p 'y-or-n-p)

See my bug report: bug#21396

Bye,
Tassilo

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> Cc: emacs-devel <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Kaushal Modi <kaushal.modi@gmail.com>
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 3 Sep 2015 20:28:22 +0300
> 
> (defalias 'yes-or-no-p 'y-or-n-p)

Why?  Just don't.

Re: yes-or-no-p prompt conditionally broken in master?

[Dmitry Gutov]

On 09/03/2015 08:43 PM, Eli Zaretskii wrote:

>> (defalias 'yes-or-no-p 'y-or-n-p)
>
> Why?

Because it saves keypresses. There's really no need to type "yes<RET>" 
fully to indicate agreement.

> Just don't.

It's been working fine for years.

Re: yes-or-no-p prompt conditionally broken in master?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

@Dmitry Yes I too have that defalias.

@Tassilo Thanks for bissecting the git and narrowing down to the problem (I
need to learn to do that).

I'm glad it's reproducible by someone :)


On Thu, Sep 3, 2015 at 1:44 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: emacs-devel <emacs-devel@gnu.org>,
> >  Stefan Monnier <monnier@iro.umontreal.ca>,
> >  Kaushal Modi <kaushal.modi@gmail.com>
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Thu, 3 Sep 2015 20:28:22 +0300
> >
> > (defalias 'yes-or-no-p 'y-or-n-p)
>
> Why?  Just don't.
>

[-- Attachment #2: Type: text/html, Size: 1160 bytes --]

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> Cc: bruce.connor.am@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  kaushal.modi@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 3 Sep 2015 20:47:07 +0300
> 
> On 09/03/2015 08:43 PM, Eli Zaretskii wrote:
> 
> >> (defalias 'yes-or-no-p 'y-or-n-p)
> >
> > Why?
> 
> Because it saves keypresses. There's really no need to type "yes<RET>" 
> fully to indicate agreement.

Then we should not use yes-or-no-p there, but y-or-n-p.

> > Just don't.
> 
> It's been working fine for years.

Sheer luck.

Re: yes-or-no-p prompt conditionally broken in master?

[Artur Malabarba]

>> > Just don't.
>>
>> It's been working fine for years.
>
> Sheer luck.

Regardless of how lucky it was, it is extremely useful. I've used it
for years too, and will be sad if it stops working completely.

Re: yes-or-no-p prompt conditionally broken in master?

[Marcin Borkowski]

On 2015-09-03, at 19:47, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 09/03/2015 08:43 PM, Eli Zaretskii wrote:
>
>>> (defalias 'yes-or-no-p 'y-or-n-p)
>>
>> Why?
>
> Because it saves keypresses. There's really no need to type "yes<RET>" 
> fully to indicate agreement.

The whole point of yes-or-no-p is to make user type something less
convenient (and less probable to hit accidentally) then just `y'.

FWIW, I have (setq confirm-kill-emacs #'yes-or-no-p) in my init.el.
I just can't count the times I pressed C-x C-c by mistake.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> Date: Thu, 3 Sep 2015 19:18:08 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: Dmitry Gutov <dgutov@yandex.ru>, emacs-devel <emacs-devel@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Kaushal Modi <kaushal.modi@gmail.com>
> 
> >> > Just don't.
> >>
> >> It's been working fine for years.
> >
> > Sheer luck.
> 
> Regardless of how lucky it was, it is extremely useful. I've used it
> for years too, and will be sad if it stops working completely.

If this is an important feature, we should have it legitimately, not
through kludges like that.

RE: yes-or-no-p prompt conditionally broken in master?

[Drew Adams]

> >> > Just don't.
> >>
> >> It's been working fine for years.
> >
> > Sheer luck.
> 
> Regardless of how lucky it was, it is extremely useful. I've used it
> for years too, and will be sad if it stops working completely.

FWIW, I agree with both Eli and those who want the regression fixed.

1. Each place such a prompting function is used, we should pick
the right function.  If `yes-or-no-p' is not right for a given
occurrence, and `y-or-n-p' is right, then let's fix that.

2. User preferences vary.  Some users never want to respond to
a `yes-or-no-p' prompt.  That's their choice.  It should be easy
for them to express their choice and have Emacs respect it.

(I do not recommend that a user replace all `yes-or-no-p' behavior
by `y-or-n-p' behavior.  But that's up to the user.)

Re: yes-or-no-p prompt conditionally broken in master?

[Dmitry Gutov]

On 09/03/2015 09:18 PM, Marcin Borkowski wrote:

> The whole point of yes-or-no-p is to make user type something less
> convenient (and less probable to hit accidentally) then just `y'.

And as a power user, I've found it immensely useful not to type that 
"less convenient" thing. If it were a problem in my usage, I'd probably 
have noticed.

> FWIW, I have (setq confirm-kill-emacs #'yes-or-no-p) in my init.el.
> I just can't count the times I pressed C-x C-c by mistake.

It's a personal choice. I don't kill Emacs too often by mistake, and 
even if I press that conbination, usually I would be greeted with 
prompts about modified buffers and running processes.

Re: yes-or-no-p prompt conditionally broken in master?

[Dmitry Gutov]

On 09/03/2015 09:02 PM, Eli Zaretskii wrote:

> Then we should not use yes-or-no-p there, but y-or-n-p.

I can't think of a place where I'd really have been better served by 
yes-or-no-p (personally). But yes-or-no-p is a good default overall.

So I believe we should support this use case, via defalias or some 
other, more appropriate, way.

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> Date: Thu, 3 Sep 2015 11:23:17 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Kaushal Modi <kaushal.modi@gmail.com>, emacs-devel <emacs-devel@gnu.org>,
>         Stefan Monnier <monnier@iro.umontreal.ca>,
>         Dmitry Gutov <dgutov@yandex.ru>
> 
> FWIW, I agree with both Eli and those who want the regression fixed.
> 
> 1. Each place such a prompting function is used, we should pick
> the right function.  If `yes-or-no-p' is not right for a given
> occurrence, and `y-or-n-p' is right, then let's fix that.
> 
> 2. User preferences vary.  Some users never want to respond to
> a `yes-or-no-p' prompt.  That's their choice.  It should be easy
> for them to express their choice and have Emacs respect it.

I agree completely, and hope that just doing (1) correctly will be
enough.  But if (1) is not enough, then I think we should fix the rest
of the use cases via a user option that redirects yes-or-no-p to
y-or-n-p.  Requesting us to drag on with supporting such defaliases is
an unjustified maintenance burden.

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 3 Sep 2015 21:25:19 +0300
> 
> > FWIW, I have (setq confirm-kill-emacs #'yes-or-no-p) in my init.el.
> > I just can't count the times I pressed C-x C-c by mistake.
> 
> It's a personal choice.

Personal choices are solved by user options, not by defaliases and
suchlikes.

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> Cc: bruce.connor.am@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>  kaushal.modi@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 3 Sep 2015 21:27:41 +0300
> 
> So I believe we should support this use case, via defalias or some 
> other, more appropriate, way.

I'm okay with supporting it, I just don't want us to be bound by a
requirement that y-or-n-p is a drop-in replacement for yes-or-no-p.
We have user options for that, let's use them.

Re: yes-or-no-p prompt conditionally broken in master?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Thu, 3 Sep 2015 21:25:19 +0300
>> 
>> > FWIW, I have (setq confirm-kill-emacs #'yes-or-no-p) in my init.el.
>> > I just can't count the times I pressed C-x C-c by mistake.
>> 
>> It's a personal choice.
>
> Personal choices are solved by user options, not by defaliases and
> suchlikes.

The Emacs manual starts with "Emacs is the extensible, customizable,
self-documenting real-time display editor."  The very first attribute
mentioned here is "extensible".  So who are we to tell users they should
not use Emacs' programming facilities for making it do what they want?

-- 
David Kastrup

Re: yes-or-no-p prompt conditionally broken in master?

[Dmitry Gutov]

On 09/03/2015 09:30 PM, Eli Zaretskii wrote:

> I'm okay with supporting it, I just don't want us to be bound by a
> requirement that y-or-n-p is a drop-in replacement for yes-or-no-p.
> We have user options for that, let's use them.

No argument from me here. Just support it somehow.

Re: yes-or-no-p prompt conditionally broken in master?

[Artur Malabarba]

>> 2. User preferences vary.  Some users never want to respond to
>> a `yes-or-no-p' prompt.  That's their choice.  It should be easy
>> for them to express their choice and have Emacs respect it.
>
> But if (1) is not enough, then I think we should fix the rest
> of the use cases via a user option that redirects yes-or-no-p to
> y-or-n-p.  Requesting us to drag on with supporting such defaliases is
> an unjustified maintenance burden.

I agree with any solution that makes it possible. Be it user option or whatnot.

Re: yes-or-no-p prompt conditionally broken in master?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

Alright. It is given that many users including myself cannot do without
y-or-n-p.
So how do we resolve it? How do we make y-or-n-p work as well as it did
before? Why is it difficult? Let's discuss the technical challenges here.

On Thu, Sep 3, 2015 at 2:43 PM Artur Malabarba <bruce.connor.am@gmail.com>
wrote:

> >> 2. User preferences vary.  Some users never want to respond to
> >> a `yes-or-no-p' prompt.  That's their choice.  It should be easy
> >> for them to express their choice and have Emacs respect it.
> >
> > But if (1) is not enough, then I think we should fix the rest
> > of the use cases via a user option that redirects yes-or-no-p to
> > y-or-n-p.  Requesting us to drag on with supporting such defaliases is
> > an unjustified maintenance burden.
>
> I agree with any solution that makes it possible. Be it user option or
> whatnot.
>

[-- Attachment #2: Type: text/html, Size: 1189 bytes --]

Re: yes-or-no-p prompt conditionally broken in master?

[Marcin Borkowski]

On 2015-09-03, at 20:25, Dmitry Gutov <dgutov@yandex.ru> wrote:

> On 09/03/2015 09:18 PM, Marcin Borkowski wrote:
>
>> The whole point of yes-or-no-p is to make user type something less
>> convenient (and less probable to hit accidentally) then just `y'.
>
> And as a power user, I've found it immensely useful not to type that 
> "less convenient" thing. If it were a problem in my usage, I'd probably 
> have noticed.

I understand.  (In fact, AFAIK, confirm-kill-emacs is the only place
I ever used yes-or-no-p, and quite often I disable even y-or-n-p,
e.g. in the case of (setq TeX-save-query nil).

OTOH, being a power user does not help _at all_ when e.g. working on
someone else's computer with a different keyboard.  ;-)

>> FWIW, I have (setq confirm-kill-emacs #'yes-or-no-p) in my init.el.
>> I just can't count the times I pressed C-x C-c by mistake.
>
> It's a personal choice. I don't kill Emacs too often by mistake, and 
> even if I press that conbination, usually I would be greeted with 
> prompts about modified buffers and running processes.

You're probably right.  It's an ancient setting in my init.el, and most
probably I don't need it anymore.  When I was a beginner, though, it
happened to me all the time, and I deeply appreciated the sheer
existence of both y-or-n-p and yes-or-no-p.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: yes-or-no-p prompt conditionally broken in master?

[Andy Moreton]

On Thu 03 Sep 2015, David Kastrup wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Dmitry Gutov <dgutov@yandex.ru>
>>> Date: Thu, 3 Sep 2015 21:25:19 +0300
>>> 
>>> > FWIW, I have (setq confirm-kill-emacs #'yes-or-no-p) in my init.el.
>>> > I just can't count the times I pressed C-x C-c by mistake.
>>> 
>>> It's a personal choice.
>>
>> Personal choices are solved by user options, not by defaliases and
>> suchlikes.
>
> The Emacs manual starts with "Emacs is the extensible, customizable,
> self-documenting real-time display editor."  The very first attribute
> mentioned here is "extensible".  So who are we to tell users they should
> not use Emacs' programming facilities for making it do what they want?

You are both right.

Extensibility has allowed users to tailor how emacs behaves, given that
no user option exists to configure this behaviour. The fact that several
people have done so indicates that a user option is needed.

    AndyM

Re: yes-or-no-p prompt conditionally broken in master?

[Katsumi Yamaoka]

On Thu, 03 Sep 2015 19:39:36 +0300, Eli Zaretskii wrote:
> FWIW, I cannot reproduce this with the current master.

I've seen it a few times yesterday.  I'll report it if I find out
a generic way to reproduce it.

In GNU Emacs 25.0.50.1 (i686-pc-cygwin, GTK+ Version 3.10.9)
 of 2015-09-03
Windowing system distributor 'The Cygwin/X Project', version 11.0.11501000
Configured using:
 'configure --verbose --with-x-toolkit=gtk3'

Re: yes-or-no-p prompt conditionally broken in master?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

@Stefan, thanks for the bug fix. I don't see this issue after updating to
this commit:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=944d77f070da388b0c6e6578a9f868e88c088940

On Thu, Sep 3, 2015 at 6:31 PM Katsumi Yamaoka <yamaoka@jpl.org> wrote:

> On Thu, 03 Sep 2015 19:39:36 +0300, Eli Zaretskii wrote:
> > FWIW, I cannot reproduce this with the current master.
>
> I've seen it a few times yesterday.  I'll report it if I find out
> a generic way to reproduce it.
>
> In GNU Emacs 25.0.50.1 (i686-pc-cygwin, GTK+ Version 3.10.9)
>  of 2015-09-03
> Windowing system distributor 'The Cygwin/X Project', version 11.0.11501000
> Configured using:
>  'configure --verbose --with-x-toolkit=gtk3'
>

[-- Attachment #2: Type: text/html, Size: 1119 bytes --]

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  emacs-devel@gnu.org,  monnier@iro.umontreal.ca,  bruce.connor.am@gmail.com,  kaushal.modi@gmail.com
> Date: Thu, 03 Sep 2015 20:33:28 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Dmitry Gutov <dgutov@yandex.ru>
> >> Date: Thu, 3 Sep 2015 21:25:19 +0300
> >> 
> >> > FWIW, I have (setq confirm-kill-emacs #'yes-or-no-p) in my init.el.
> >> > I just can't count the times I pressed C-x C-c by mistake.
> >> 
> >> It's a personal choice.
> >
> > Personal choices are solved by user options, not by defaliases and
> > suchlikes.
> 
> The Emacs manual starts with "Emacs is the extensible, customizable,
> self-documenting real-time display editor."  The very first attribute
> mentioned here is "extensible".  So who are we to tell users they should
> not use Emacs' programming facilities for making it do what they want?

I'm not telling them that.  I'm suggesting to tell them that Emacs
maintenance is not going to promise such tricks, bsed on accidental
identity of 2 separate APIs, will always work.  They should expect it
to break without notice.

Re: yes-or-no-p prompt conditionally broken in master?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not telling them that.  I'm suggesting to tell them that Emacs
> maintenance is not going to promise such tricks, bsed on accidental
> identity of 2 separate APIs, will always work.  They should expect it
> to break without notice.

You are barking up the wrong tree.  The discussed issue has nothing to
do with yes-or-no-p or y-or-n-p or the alising thereof (and I expect
this aliasing to always work, because the identity of the APIs is not
accidental).

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Fri, 04 Sep 2015 08:48:13 +0200
> Cc: David Kastrup <dak@gnu.org>, kaushal.modi@gmail.com,
> 	bruce.connor.am@gmail.com, emacs-devel@gnu.org,
> 	monnier@iro.umontreal.ca, dgutov@yandex.ru
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not telling them that.  I'm suggesting to tell them that Emacs
> > maintenance is not going to promise such tricks, bsed on accidental
> > identity of 2 separate APIs, will always work.  They should expect it
> > to break without notice.
> 
> You are barking up the wrong tree.

You've elided the tree I was barking up.

> The discussed issue has nothing to
> do with yes-or-no-p or y-or-n-p or the alising thereof

There was more than one "discussed issue" here.  At least one of them
has everything to do with aliasing of these 2.

> (and I expect this aliasing to always work, because the identity of
> the APIs is not accidental).

It might indeed always work, but you shouldn't expect that.

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> Date: Thu, 3 Sep 2015 19:43:25 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: emacs-devel <emacs-devel@gnu.org>, Brief Busters <dgutov@yandex.ru>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>,
> 	Drew Adams <drew.adams@oracle.com>, Kaushal Modi <kaushal.modi@gmail.com>
> 
> >> 2. User preferences vary.  Some users never want to respond to
> >> a `yes-or-no-p' prompt.  That's their choice.  It should be easy
> >> for them to express their choice and have Emacs respect it.
> >
> > But if (1) is not enough, then I think we should fix the rest
> > of the use cases via a user option that redirects yes-or-no-p to
> > y-or-n-p.  Requesting us to drag on with supporting such defaliases is
> > an unjustified maintenance burden.
> 
> I agree with any solution that makes it possible. Be it user option or whatnot.

Does anyone see a reason why we even have 2 functions, instead of just
one that can either accept a single character or a string?  Let alone
why yes-or-no-p is implemented in C, while y-or-n-p in Lisp?

Any objections to removing yes-or-no-p (with a defalias for backward
compatibility, of course) and making y-or-n-p serve both duties,
controlled by some defcustom?

Re: yes-or-no-p prompt conditionally broken in master?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 3 Sep 2015 19:43:25 +0100
>> From: Artur Malabarba <bruce.connor.am@gmail.com>
>> Cc: emacs-devel <emacs-devel@gnu.org>, Brief Busters <dgutov@yandex.ru>,
>> 	Stefan Monnier <monnier@iro.umontreal.ca>,
>> 	Drew Adams <drew.adams@oracle.com>, Kaushal Modi
>> <kaushal.modi@gmail.com>
>> 
>> >> 2. User preferences vary.  Some users never want to respond to
>> >> a `yes-or-no-p' prompt.  That's their choice.  It should be easy
>> >> for them to express their choice and have Emacs respect it.
>> >
>> > But if (1) is not enough, then I think we should fix the rest
>> > of the use cases via a user option that redirects yes-or-no-p to
>> > y-or-n-p.  Requesting us to drag on with supporting such defaliases is
>> > an unjustified maintenance burden.
>> 
>> I agree with any solution that makes it possible. Be it user option
>> or whatnot.
>
> Does anyone see a reason why we even have 2 functions, instead of just
> one that can either accept a single character or a string?

How would that even work?

> Let alone why yes-or-no-p is implemented in C, while y-or-n-p in Lisp?
>
> Any objections to removing yes-or-no-p (with a defalias for backward
> compatibility, of course) and making y-or-n-p serve both duties,
> controlled by some defcustom?

You mean, controlled by an optional argument?  With some defcustom for
specifying the interpretation of the optional argument?

Because otherwise you'll have a hard time retaining the current default
behavior for emacs -Q.

-- 
David Kastrup

Re: yes-or-no-p prompt conditionally broken in master?

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> Any objections to removing yes-or-no-p (with a defalias for backward
> compatibility, of course) and making y-or-n-p serve both duties,
> controlled by some defcustom?

None on my side.

(fset 'yes-or-no-p 'y-or-n-p) is the most ancient piece of .emacs.el
that lives in my configuration, and I guess many users have it too.

Getting rid of something beginners half understand (fset?!) is a good
thing, even if I'll get emotional when C-k'ing this line.

-- 
 Bastien

Re: yes-or-no-p prompt conditionally broken in master?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> It might indeed always work, but you shouldn't expect that.

Yes, I do.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: yes-or-no-p prompt conditionally broken in master?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Any objections to removing yes-or-no-p (with a defalias for backward
> compatibility, of course) and making y-or-n-p serve both duties,
> controlled by some defcustom?

That doesn't make sense.  They implement different intented meaning.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: yes-or-no-p prompt conditionally broken in master?

[Marcin Borkowski]

On 2015-09-04, at 11:26, Andreas Schwab <schwab@linux-m68k.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Any objections to removing yes-or-no-p (with a defalias for backward
>> compatibility, of course) and making y-or-n-p serve both duties,
>> controlled by some defcustom?
>
> That doesn't make sense.  They implement different intented meaning.

+1.  They serve different purposes, and they are both needed.  At the
same time.  While I understand that someone might want to make
yes-or-no-p behave like y-or-n-p all the time, someone else (like, say,
me) might want to use y-or-n-p in places where just a confirmation is
a nice thing to have, and yes-or-no-p in places where you really want to
make sure that the user does not accidentally press `y'.

> Andreas.

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: yes-or-no-p prompt conditionally broken in master?

[David Kastrup]

Marcin Borkowski <mbork@mbork.pl> writes:

> On 2015-09-04, at 11:26, Andreas Schwab <schwab@linux-m68k.org> wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> Any objections to removing yes-or-no-p (with a defalias for backward
>>> compatibility, of course) and making y-or-n-p serve both duties,
>>> controlled by some defcustom?
>>
>> That doesn't make sense.  They implement different intented meaning.
>
> +1.  They serve different purposes, and they are both needed.  At the
> same time.  While I understand that someone might want to make
> yes-or-no-p behave like y-or-n-p all the time, someone else (like, say,
> me) might want to use y-or-n-p in places where just a confirmation is
> a nice thing to have, and yes-or-no-p in places where you really want to
> make sure that the user does not accidentally press `y'.

Not just 'y'.  y-or-n-p is quite apt to turn any kind of typeahead into
an unintended answer.  From its DOC string:

    No confirmation of the answer is requested; a single character is
    enough.  SPC also means yes, and DEL means no.

-- 
David Kastrup

Re: yes-or-no-p prompt conditionally broken in master?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

> Any objections to removing yes-or-no-p (with a defalias for backward
compatibility, of course) and making y-or-n-p serve both duties, controlled
by some defcustom?

I don't mind that.

--
Kaushal Modi
On Sep 4, 2015 7:03 AM, "David Kastrup" <dak@gnu.org> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
> > On 2015-09-04, at 11:26, Andreas Schwab <schwab@linux-m68k.org> wrote:
> >
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >>> Any objections to removing yes-or-no-p (with a defalias for backward
> >>> compatibility, of course) and making y-or-n-p serve both duties,
> >>> controlled by some defcustom?
> >>
> >> That doesn't make sense.  They implement different intented meaning.
> >
> > +1.  They serve different purposes, and they are both needed.  At the
> > same time.  While I understand that someone might want to make
> > yes-or-no-p behave like y-or-n-p all the time, someone else (like, say,
> > me) might want to use y-or-n-p in places where just a confirmation is
> > a nice thing to have, and yes-or-no-p in places where you really want to
> > make sure that the user does not accidentally press `y'.
>
> Not just 'y'.  y-or-n-p is quite apt to turn any kind of typeahead into
> an unintended answer.  From its DOC string:
>
>     No confirmation of the answer is requested; a single character is
>     enough.  SPC also means yes, and DEL means no.
>
> --
> David Kastrup
>

[-- Attachment #2: Type: text/html, Size: 2007 bytes --]

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: bruce.connor.am@gmail.com,  kaushal.modi@gmail.com,  dgutov@yandex.ru,  monnier@iro.umontreal.ca,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 04 Sep 2015 11:26:46 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Any objections to removing yes-or-no-p (with a defalias for backward
> > compatibility, of course) and making y-or-n-p serve both duties,
> > controlled by some defcustom?
> 
> That doesn't make sense.  They implement different intented meaning.

Sorry, I lost you: what different meaning is that?

The doc strings of the two functions say the same:

  (yes-or-no-p PROMPT)

  Ask user a yes-or-no question.
  Return t if answer is yes, and nil if the answer is no.
  PROMPT is the string to display to ask the question.  It should end in
  a space; ‘yes-or-no-p’ adds "(yes or no) " to it.

vs

  (y-or-n-p PROMPT)

  Ask user a "y or n" question.  Return t if answer is "y".
  PROMPT is the string to display to ask the question.  It should
  end in a space; ‘y-or-n-p’ adds "(y or n) " to it.

Re: yes-or-no-p prompt conditionally broken in master?

[Wolfgang Jenkner]

On Thu, Sep 03 2015, Eli Zaretskii wrote:

>> Cc: emacs-devel <emacs-devel@gnu.org>,
>>  Stefan Monnier <monnier@iro.umontreal.ca>,
>>  Kaushal Modi <kaushal.modi@gmail.com>
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Thu, 3 Sep 2015 20:28:22 +0300
>> 
>> (defalias 'yes-or-no-p 'y-or-n-p)
>
> Why?  Just don't.

FWIW, I don't, but I've been aware of this trick for a long time as part
of the emacs folklore (when I search for yes-or-no-p, DuckDuckGo
suggests the emacs wiki page[*], which mentions it, right after some
mirror of the Common Lisp Hyperspec)

So, IMHO, you are right in general, of course, that emacs developers
can't guarantee that such tricks will always work, but I don't think
that it would make sense to break user expectations in this particular
case.

[*] http://www.emacswiki.org/emacs/YesOrNoP

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: Marcin Borkowski <mbork@mbork.pl>
> Date: Fri, 04 Sep 2015 12:32:04 +0200
> 
> 
> On 2015-09-04, at 11:26, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> Any objections to removing yes-or-no-p (with a defalias for backward
> >> compatibility, of course) and making y-or-n-p serve both duties,
> >> controlled by some defcustom?
> >
> > That doesn't make sense.  They implement different intented meaning.
> 
> +1.  They serve different purposes, and they are both needed.

This is a misunderstanding: I didn't suggest to remove any
functionality.  You will still be able to do exactly what each of
these functions do, just their implementation will be in a single
function.

> While I understand that someone might want to make yes-or-no-p
> behave like y-or-n-p all the time, someone else (like, say, me)
> might want to use y-or-n-p in places where just a confirmation is a
> nice thing to have, and yes-or-no-p in places where you really want
> to make sure that the user does not accidentally press `y'.

That's a no-brainer, and I never said anything to the contrary.

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: bruce.connor.am@gmail.com,  kaushal.modi@gmail.com,  dgutov@yandex.ru,  monnier@iro.umontreal.ca,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 04 Sep 2015 11:14:13 +0200
> 
> > Any objections to removing yes-or-no-p (with a defalias for backward
> > compatibility, of course) and making y-or-n-p serve both duties,
> > controlled by some defcustom?
> 
> You mean, controlled by an optional argument?  With some defcustom for
> specifying the interpretation of the optional argument?

Yes, somethng like that.  But it's possible even without the optional
argument.

> Because otherwise you'll have a hard time retaining the current default
> behavior for emacs -Q.

Well, we could have one function bind the defcustom and then call the
other one.  Then we won't even need a defalias for backward
compatibility.

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: Wolfgang Jenkner <wjenkner@inode.at>
> Cc: Dmitry Gutov <dgutov@yandex.ru>,  kaushal.modi@gmail.com,  monnier@iro.umontreal.ca,  bruce.connor.am@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 04 Sep 2015 14:29:57 +0200
> 
> FWIW, I don't, but I've been aware of this trick for a long time as part
> of the emacs folklore (when I search for yes-or-no-p, DuckDuckGo
> suggests the emacs wiki page[*], which mentions it, right after some
> mirror of the Common Lisp Hyperspec)
> 
> So, IMHO, you are right in general, of course, that emacs developers
> can't guarantee that such tricks will always work, but I don't think
> that it would make sense to break user expectations in this particular
> case.

I'm not going to break it just for the joy of breaking it, but if
there's a good reason to change one of the APIs, we shouldn't back off
just because of this trick.  Especially if we provide an alternative
method for doing the same (which is what is being discussed now).

Re: yes-or-no-p prompt conditionally broken in master?

[Marcin Borkowski]

On 2015-09-04, at 14:30, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Marcin Borkowski <mbork@mbork.pl>
>> Date: Fri, 04 Sep 2015 12:32:04 +0200
>> 
>> 
>> On 2015-09-04, at 11:26, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> 
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> >
>> >> Any objections to removing yes-or-no-p (with a defalias for backward
>> >> compatibility, of course) and making y-or-n-p serve both duties,
>> >> controlled by some defcustom?
>> >
>> > That doesn't make sense.  They implement different intented meaning.
>> 
>> +1.  They serve different purposes, and they are both needed.
>
> This is a misunderstanding: I didn't suggest to remove any
> functionality.  You will still be able to do exactly what each of
> these functions do, just their implementation will be in a single
> function.

I see.  Sorry.

>> While I understand that someone might want to make yes-or-no-p
>> behave like y-or-n-p all the time, someone else (like, say, me)
>> might want to use y-or-n-p in places where just a confirmation is a
>> nice thing to have, and yes-or-no-p in places where you really want
>> to make sure that the user does not accidentally press `y'.
>
> That's a no-brainer, and I never said anything to the contrary.

Great!

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: yes-or-no-p prompt conditionally broken in master?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: bruce.connor.am@gmail.com,  kaushal.modi@gmail.com,  dgutov@yandex.ru,  monnier@iro.umontreal.ca,  drew.adams@oracle.com,  emacs-devel@gnu.org
>> Date: Fri, 04 Sep 2015 11:26:46 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Any objections to removing yes-or-no-p (with a defalias for backward
>> > compatibility, of course) and making y-or-n-p serve both duties,
>> > controlled by some defcustom?
>> 
>> That doesn't make sense.  They implement different intented meaning.
>
> Sorry, I lost you: what different meaning is that?

(elisp) Yes-or-No Queries

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: bruce.connor.am@gmail.com,  kaushal.modi@gmail.com,  dgutov@yandex.ru,  monnier@iro.umontreal.ca,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 04 Sep 2015 14:40:00 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: bruce.connor.am@gmail.com,  kaushal.modi@gmail.com,  dgutov@yandex.ru,  monnier@iro.umontreal.ca,  drew.adams@oracle.com,  emacs-devel@gnu.org
> >> Date: Fri, 04 Sep 2015 11:26:46 +0200
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > Any objections to removing yes-or-no-p (with a defalias for backward
> >> > compatibility, of course) and making y-or-n-p serve both duties,
> >> > controlled by some defcustom?
> >> 
> >> That doesn't make sense.  They implement different intented meaning.
> >
> > Sorry, I lost you: what different meaning is that?
> 
> (elisp) Yes-or-No Queries

Still no clue, sorry.

Just to be sure we are talking about the same thing: the signature of
both functions and the return value are the same.  What I propose is
to change the body so that it could act like one or the other,
depending on the value of some defcustom.

If you still think this is wrong, please elaborate.

Re: yes-or-no-p prompt conditionally broken in master?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

> Well, we could have one function bind the defcustom and then call the
other one.  Then we won't even need a defalias for backward
compatibility.

That's awesome! So I believe it will be something like this?

<psuedocode follows>

(defcustom yes-or-no-quick nil)

;; yes-or-no-p now implemented in elisp instead of C
(defun yes-or-no-p (prompt)
  (if yes-or-no-p-quick
      (progn
         ;; y-or-n-p implementation
         )
     (progn
        ;; legacy yes-or-no-p implementation
        )))

;; y-or-n-p redefined
(defun y-or-n-p (prompt)
  (let ((yes-or-no-quick t))
     (yes-or-no-p prompt)))



On Fri, Sep 4, 2015 at 8:40 AM Andreas Schwab <schwab@linux-m68k.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: bruce.connor.am@gmail.com,  kaushal.modi@gmail.com,
> dgutov@yandex.ru,  monnier@iro.umontreal.ca,  drew.adams@oracle.com,
> emacs-devel@gnu.org
> >> Date: Fri, 04 Sep 2015 11:26:46 +0200
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> > Any objections to removing yes-or-no-p (with a defalias for backward
> >> > compatibility, of course) and making y-or-n-p serve both duties,
> >> > controlled by some defcustom?
> >>
> >> That doesn't make sense.  They implement different intented meaning.
> >
> > Sorry, I lost you: what different meaning is that?
>
> (elisp) Yes-or-No Queries
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>

[-- Attachment #2: Type: text/html, Size: 3451 bytes --]

Re: yes-or-no-p prompt conditionally broken in master?

[Stefan Monnier]

> Any objections to removing yes-or-no-p (with a defalias for backward
> compatibility, of course) and making y-or-n-p serve both duties,
> controlled by some defcustom?

I don't object to moving yes-or-no-p to Elisp and/or to share code
between yes-or-no-p and y-or-n-p, but the default behavior of Emacs
should still be that yes-or-no-p uses the minibuffer and requires the
user to type something like `y e s RET' while y-or-n-p is satisfied with
a simple `y' or `SPC'.


        Stefan

Re: yes-or-no-p prompt conditionally broken in master?

[Alan Mackenzie]

Hello, Eli.

On Fri, Sep 04, 2015 at 03:58:52PM +0300, Eli Zaretskii wrote:
> > From: Andreas Schwab <schwab@linux-m68k.org>
> > Cc: bruce.connor.am@gmail.com,  kaushal.modi@gmail.com,  dgutov@yandex.ru,  monnier@iro.umontreal.ca,  drew.adams@oracle.com,  emacs-devel@gnu.org
> > Date: Fri, 04 Sep 2015 14:40:00 +0200

> > Eli Zaretskii <eliz@gnu.org> writes:

> > >> From: Andreas Schwab <schwab@linux-m68k.org>
> > >> Cc: bruce.connor.am@gmail.com,  kaushal.modi@gmail.com,  dgutov@yandex.ru,  monnier@iro.umontreal.ca,  drew.adams@oracle.com,  emacs-devel@gnu.org
> > >> Date: Fri, 04 Sep 2015 11:26:46 +0200

> > >> Eli Zaretskii <eliz@gnu.org> writes:

> > >> > Any objections to removing yes-or-no-p (with a defalias for backward
> > >> > compatibility, of course) and making y-or-n-p serve both duties,
> > >> > controlled by some defcustom?

> > >> That doesn't make sense.  They implement different intented meaning.

> > > Sorry, I lost you: what different meaning is that?

> > (elisp) Yes-or-No Queries

> Still no clue, sorry.

> Just to be sure we are talking about the same thing: the signature of
> both functions and the return value are the same.  What I propose is
> to change the body so that it could act like one or the other,
> depending on the value of some defcustom.

I know I'm a bit late to this thread, but I find the above worrying,
depending on the "depending".

If the defcustom has three values "Always-y-or-n", "Always-yes-or-no",
"depends-on-the-particular-invocation", I'm fine.  With just the first
two alternatives, I wouldn't like it.

i.e. each formerly yes-or-no-p call would have to be something like

    (y-or-n-p "Really? " t)

.

> If you still think this is wrong, please elaborate.

I'm wondering whether coalescing these two function is more trouble than
it's worth.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: yes-or-no-p prompt conditionally broken in master?

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Any objections to removing yes-or-no-p (with a defalias for backward
>> compatibility, of course) and making y-or-n-p serve both duties,
>> controlled by some defcustom?
>
> I don't object to moving yes-or-no-p to Elisp and/or to share code
> between yes-or-no-p and y-or-n-p, but the default behavior of Emacs
> should still be that yes-or-no-p uses the minibuffer and requires the
> user to type something like `y e s RET' while y-or-n-p is satisfied with
> a simple `y' or `SPC'.

Difficult since y-or-n-p allows scrolling the current window while using
the echo area for its prompt, and yes-or-no-p instead gives you a full
minibuffer entry as the current window.

-- 
David Kastrup

RE: yes-or-no-p prompt conditionally broken in master?

[Drew Adams]

> That's awesome! So I believe it will be something like this?
> 
> (defcustom yes-or-no-quick nil)
> 
> ;; yes-or-no-p now implemented in elisp instead of C
> (defun yes-or-no-p (prompt)
>   (if yes-or-no-p-quick
>       (progn
>          ;; y-or-n-p implementation
>         )
>      (progn
>         ;; legacy yes-or-no-p implementation
>         )))
> 
> ;; y-or-n-p redefined
> (defun y-or-n-p (prompt)
>   (let ((yes-or-no-quick t))
>      (yes-or-no-p prompt)))

Certainly not.  Although Eli expressed himself very poorly
in his proposal, I don't think that is what he meant (I
certainly hope not).

Presumably the defcustom would allow at least 3 possibilities:

1. Always use the traditional y-or-n-p behavior.
2. Always use the traditional yes-or-no-p behavior.
3. Always respect whichever behavior is expressed in the call.

#3 would be equivalent to the out-of-the-box behavior today.
With #3 the behavior in one code context could be like y-or-n-p
and in a different context it could be like yes-or-no-p.

At least this is what I hope he meant.  What he actually said
can, however, give the impression that only possibilites #1
and #2 would exist.  I cannot believe that is what he meant,
given his other posts about Emacs carefully judging which
behavior to code in any given context.


On Fri, Sep 4, 2015 at 8:40 AM Andreas Schwab <schwab@linux-m68k.org> wrote:
Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: bruce.connor.am@gmail.com,  kaushal.modi@gmail.com,  dgutov@yandex.ru,  monnier@iro.umontreal.ca,  drew.adams@oracle.com,  emacs-devel@gnu.org
>> Date: Fri, 04 Sep 2015 11:26:46 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Any objections to removing yes-or-no-p (with a defalias for backward
>> > compatibility, of course) and making y-or-n-p serve both duties,
>> > controlled by some defcustom?
>>
>> That doesn't make sense.  They implement different intented meaning.
>
> Sorry, I lost you: what different meaning is that?

(elisp) Yes-or-No Queries

Andreas.

--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: yes-or-no-p prompt conditionally broken in master?

[Chad Brown]

> On 04 Sep 2015, at 05:58, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> Just to be sure we are talking about the same thing: the signature of
> both functions and the return value are the same.  What I propose is
> to change the body so that it could act like one or the other,
> depending on the value of some defcustom.
> 
> If you still think this is wrong, please elaborate.

What I would like is for it to continue to be possible to use the
functionality of both yes-or-no-p and y-or-n-p in the same emacs,
with different code making different choices. I believe that others
are also asking for this functionality. In my specific case, I
usually use y-or-n-p in my own code, but confirm-kill-emacs is set
to yes-or-no-p, as are a few other hard-to-reverse confirmations.
Your message initially made me think you were suggesting a global
defcustom for switching all uses of a unified function within an
emacs; I don’t want that. I don’t care (and doubt others do) if either
or both are implemented in C or in elisp, that they are implemented
differently, etc.

Thanks!
~Chad

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: bruce.connor.am@gmail.com,  emacs-devel@gnu.org,  dgutov@yandex.ru,  drew.adams@oracle.com,  kaushal.modi@gmail.com
> Date: Fri, 04 Sep 2015 09:24:41 -0400
> 
> > Any objections to removing yes-or-no-p (with a defalias for backward
> > compatibility, of course) and making y-or-n-p serve both duties,
> > controlled by some defcustom?
> 
> I don't object to moving yes-or-no-p to Elisp and/or to share code
> between yes-or-no-p and y-or-n-p, but the default behavior of Emacs
> should still be that yes-or-no-p uses the minibuffer and requires the
> user to type something like `y e s RET' while y-or-n-p is satisfied with
> a simple `y' or `SPC'.

Of course.  That goes without saying.  There was no intent to make any
incompatible changes of behavior, just let users have an option to
easily replace the yes-or-no-p behavior with y-or-n-p one.

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  kaushal.modi@gmail.com,  dgutov@yandex.ru,  drew.adams@oracle.com,  bruce.connor.am@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 04 Sep 2015 15:49:58 +0200
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> Any objections to removing yes-or-no-p (with a defalias for backward
> >> compatibility, of course) and making y-or-n-p serve both duties,
> >> controlled by some defcustom?
> >
> > I don't object to moving yes-or-no-p to Elisp and/or to share code
> > between yes-or-no-p and y-or-n-p, but the default behavior of Emacs
> > should still be that yes-or-no-p uses the minibuffer and requires the
> > user to type something like `y e s RET' while y-or-n-p is satisfied with
> > a simple `y' or `SPC'.
> 
> Difficult since y-or-n-p allows scrolling the current window while using
> the echo area for its prompt, and yes-or-no-p instead gives you a full
> minibuffer entry as the current window.

Not difficult at all, since we could start by lumping both bodies into
a single function.

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: Chad Brown <yandros@gmail.com>
> Date: Fri, 4 Sep 2015 10:31:20 -0700
> 
> What I would like is for it to continue to be possible to use the
> functionality of both yes-or-no-p and y-or-n-p in the same emacs,
> with different code making different choices.

That's not the intent, at least not mine.  What I intend to do is let
users do the equivalent of globally replacing yes-or-no-p with
y-or-n-p, like they do with defalias or fset.

If that is not enough for your use case with confirm-kill-emacs,
please file a bug report describing the feature you'd like to have in
that situation.  The solution might or might not be in yes-or-no-p.

> Your message initially made me think you were suggesting a global
> defcustom for switching all uses of a unified function within an
> emacs;

It is.

> I don’t want that.

It's a defcustom; you don't have to use it unless you want.

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> Date: Fri, 4 Sep 2015 13:34:39 +0000
> Cc: Andreas Schwab <schwab@linux-m68k.org>, kaushal.modi@gmail.com,
>   bruce.connor.am@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>   dgutov@yandex.ru, drew.adams@oracle.com
> From: Alan Mackenzie <acm@muc.de>
> 
> > Just to be sure we are talking about the same thing: the signature of
> > both functions and the return value are the same.  What I propose is
> > to change the body so that it could act like one or the other,
> > depending on the value of some defcustom.
> 
> I know I'm a bit late to this thread, but I find the above worrying,
> depending on the "depending".
> 
> If the defcustom has three values "Always-y-or-n", "Always-yes-or-no",
> "depends-on-the-particular-invocation", I'm fine.  With just the first
> two alternatives, I wouldn't like it.

The intent is to provide a predicate defcustom that allows to cause
yes-or-no-p behave like y-or-n-p.  y-or-n-p will always behave as it
does, and I didn't intend to change that, as I don't see the use case
for that.

If you still want the 3rd alternative, please describe the use cases
that would need it.

> I'm wondering whether coalescing these two function is more trouble than
> it's worth.

Please don't worry about the implementation aspects.  It's not rocket
science in any case.

Re: yes-or-no-p prompt conditionally broken in master?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 4 Sep 2015 13:34:39 +0000
>> Cc: Andreas Schwab <schwab@linux-m68k.org>, kaushal.modi@gmail.com,
>>   bruce.connor.am@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
>>   dgutov@yandex.ru, drew.adams@oracle.com
>> From: Alan Mackenzie <acm@muc.de>
>> 
>> > Just to be sure we are talking about the same thing: the signature of
>> > both functions and the return value are the same.  What I propose is
>> > to change the body so that it could act like one or the other,
>> > depending on the value of some defcustom.
>> 
>> I know I'm a bit late to this thread, but I find the above worrying,
>> depending on the "depending".
>> 
>> If the defcustom has three values "Always-y-or-n", "Always-yes-or-no",
>> "depends-on-the-particular-invocation", I'm fine.  With just the first
>> two alternatives, I wouldn't like it.
>
> The intent is to provide a predicate defcustom that allows to cause
> yes-or-no-p behave like y-or-n-p.  y-or-n-p will always behave as it
> does, and I didn't intend to change that, as I don't see the use case
> for that.

Reliable translation into selection boxes when feeding emacs -batch from
a script?  Predictable behavior when navigating Emacs by voice?  Some
people may prefer saying "yes" to saying "why".

-- 
David Kastrup

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Alan Mackenzie <acm@muc.de>,  kaushal.modi@gmail.com,  bruce.connor.am@gmail.com,  emacs-devel@gnu.org,  schwab@linux-m68k.org,  monnier@iro.umontreal.ca,  dgutov@yandex.ru,  drew.adams@oracle.com
> Date: Fri, 04 Sep 2015 20:14:51 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The intent is to provide a predicate defcustom that allows to cause
> > yes-or-no-p behave like y-or-n-p.  y-or-n-p will always behave as it
> > does, and I didn't intend to change that, as I don't see the use case
> > for that.
> 
> Reliable translation into selection boxes when feeding emacs -batch from
> a script?

y-or-n-p already does TRT in that case (no dialog boxes in -batch).

> Predictable behavior when navigating Emacs by voice?

I don't see the relevance, please elaborate.

> Some people may prefer saying "yes" to saying "why".

Likewise.

Re: yes-or-no-p prompt conditionally broken in master?

[Alan Mackenzie]

Hello, Eli.

On Fri, Sep 04, 2015 at 08:56:46PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 4 Sep 2015 13:34:39 +0000
> > Cc: Andreas Schwab <schwab@linux-m68k.org>, kaushal.modi@gmail.com,
> >   bruce.connor.am@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
> >   dgutov@yandex.ru, drew.adams@oracle.com
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > If the defcustom has three values "Always-y-or-n", "Always-yes-or-no",
> > "depends-on-the-particular-invocation", I'm fine.  With just the first
> > two alternatives, I wouldn't like it.

> The intent is to provide a predicate defcustom that allows to cause
> yes-or-no-p behave like y-or-n-p.  y-or-n-p will always behave as it
> does, and I didn't intend to change that, as I don't see the use case
> for that.

> If you still want the 3rd alternative, please describe the use cases
> that would need it.

No, I don't.  I thought somebody else did.

There's been a fair amount of misunderstanding in this thread.  Sorry
for adding to it.

> > I'm wondering whether coalescing these two function is more trouble than
> > it's worth.

> Please don't worry about the implementation aspects.  It's not rocket
> science in any case.

OK.  Have a good weekend!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: yes-or-no-p prompt conditionally broken in master?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: Alan Mackenzie <acm@muc.de>, kaushal.modi@gmail.com,
>> bruce.connor.am@gmail.com, emacs-devel@gnu.org,
>> schwab@linux-m68k.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>> drew.adams@oracle.com
>> Date: Fri, 04 Sep 2015 20:14:51 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > The intent is to provide a predicate defcustom that allows to cause
>> > yes-or-no-p behave like y-or-n-p.  y-or-n-p will always behave as it
>> > does, and I didn't intend to change that, as I don't see the use case
>> > for that.
>> 
>> Reliable translation into selection boxes when feeding emacs -batch from
>> a script?
>
> y-or-n-p already does TRT in that case (no dialog boxes in -batch).

Feeding emacs -batch _from_ a script.  Meaning the script supplies "yes"
and "no".

>> Predictable behavior when navigating Emacs by voice?
>
> I don't see the relevance, please elaborate.

Same as above.  External input translated into a source for consumption
by Emacs.

>> Some people may prefer saying "yes" to saying "why".
>
> Likewise.

"why" is phonetically the same as "y".  Which means that it's likely
harder to generate just "y" from voice than "yes".

-- 
David Kastrup

Re: yes-or-no-p prompt conditionally broken in master?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

@Eli, @Drew

Would this psuedocode work?

(progn
  ;; Possible values: nil, 'quick, 'verbose
  ;; (defconst yes-or-no-option nil)
  ;; (defconst yes-or-no-option 'quick)
  (defconst yes-or-no-option 'verbose)
  ;; If nil, yes-or-no-p and y-or-n-p will work their traditional ways
  ;; If 'quick , both yes-or-no-p and y-or-n-p will work like y-or-n-p
  ;; If 'verbose , both yes-or-no-p and y-or-n-p will work like yes-or-no-p

  ;; yes-or-no-p now implemented in elisp instead of C
  (defun yes-or-no-p (prompt)
    (if (eq yes-or-no-option 'quick)
        (message "y/n")
      (message "yes/no")))

  ;; y-or-n-p redefined
  (defun y-or-n-p (prompt)
    (let* ((orig--yes-or-no-option yes-or-no-option)
           (yes-or-no-option (if (eq orig--yes-or-no-option 'verbose)
                                 'verbose
                               'quick)))
      (yes-or-no-p prompt)))

  (message "yes-or-no-p:")
  (yes-or-no-p "Q? ")
  (message "y-or-n-p:")
  (y-or-n-p "Q? ")
  nil)

On Fri, Sep 4, 2015 at 2:50 PM David Kastrup <dak@gnu.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: David Kastrup <dak@gnu.org>
> >> Cc: Alan Mackenzie <acm@muc.de>, kaushal.modi@gmail.com,
> >> bruce.connor.am@gmail.com, emacs-devel@gnu.org,
> >> schwab@linux-m68k.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
> >> drew.adams@oracle.com
> >> Date: Fri, 04 Sep 2015 20:14:51 +0200
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> > The intent is to provide a predicate defcustom that allows to cause
> >> > yes-or-no-p behave like y-or-n-p.  y-or-n-p will always behave as it
> >> > does, and I didn't intend to change that, as I don't see the use case
> >> > for that.
> >>
> >> Reliable translation into selection boxes when feeding emacs -batch from
> >> a script?
> >
> > y-or-n-p already does TRT in that case (no dialog boxes in -batch).
>
> Feeding emacs -batch _from_ a script.  Meaning the script supplies "yes"
> and "no".
>
> >> Predictable behavior when navigating Emacs by voice?
> >
> > I don't see the relevance, please elaborate.
>
> Same as above.  External input translated into a source for consumption
> by Emacs.
>
> >> Some people may prefer saying "yes" to saying "why".
> >
> > Likewise.
>
> "why" is phonetically the same as "y".  Which means that it's likely
> harder to generate just "y" from voice than "yes".
>
> --
> David Kastrup
>

[-- Attachment #2: Type: text/html, Size: 4130 bytes --]

Re: yes-or-no-p prompt conditionally broken in master?

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]

Of course I forgot to mention that (message "y/n") is supposed to be the
traditional y-or-n-p implementation and (message "yes/no") is supposed to
be the traditional yes-or-no-p implementation.

On Fri, Sep 4, 2015 at 2:52 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> @Eli, @Drew
>
> Would this psuedocode work?
>
> (progn
>   ;; Possible values: nil, 'quick, 'verbose
>   ;; (defconst yes-or-no-option nil)
>   ;; (defconst yes-or-no-option 'quick)
>   (defconst yes-or-no-option 'verbose)
>   ;; If nil, yes-or-no-p and y-or-n-p will work their traditional ways
>   ;; If 'quick , both yes-or-no-p and y-or-n-p will work like y-or-n-p
>   ;; If 'verbose , both yes-or-no-p and y-or-n-p will work like yes-or-no-p
>
>   ;; yes-or-no-p now implemented in elisp instead of C
>   (defun yes-or-no-p (prompt)
>     (if (eq yes-or-no-option 'quick)
>         (message "y/n")
>       (message "yes/no")))
>
>   ;; y-or-n-p redefined
>   (defun y-or-n-p (prompt)
>     (let* ((orig--yes-or-no-option yes-or-no-option)
>            (yes-or-no-option (if (eq orig--yes-or-no-option 'verbose)
>                                  'verbose
>                                'quick)))
>       (yes-or-no-p prompt)))
>
>   (message "yes-or-no-p:")
>   (yes-or-no-p "Q? ")
>   (message "y-or-n-p:")
>   (y-or-n-p "Q? ")
>   nil)
>
> On Fri, Sep 4, 2015 at 2:50 PM David Kastrup <dak@gnu.org> wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: David Kastrup <dak@gnu.org>
>> >> Cc: Alan Mackenzie <acm@muc.de>, kaushal.modi@gmail.com,
>> >> bruce.connor.am@gmail.com, emacs-devel@gnu.org,
>> >> schwab@linux-m68k.org, monnier@iro.umontreal.ca, dgutov@yandex.ru,
>> >> drew.adams@oracle.com
>> >> Date: Fri, 04 Sep 2015 20:14:51 +0200
>> >>
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >>
>> >> > The intent is to provide a predicate defcustom that allows to cause
>> >> > yes-or-no-p behave like y-or-n-p.  y-or-n-p will always behave as it
>> >> > does, and I didn't intend to change that, as I don't see the use case
>> >> > for that.
>> >>
>> >> Reliable translation into selection boxes when feeding emacs -batch
>> from
>> >> a script?
>> >
>> > y-or-n-p already does TRT in that case (no dialog boxes in -batch).
>>
>> Feeding emacs -batch _from_ a script.  Meaning the script supplies "yes"
>> and "no".
>>
>> >> Predictable behavior when navigating Emacs by voice?
>> >
>> > I don't see the relevance, please elaborate.
>>
>> Same as above.  External input translated into a source for consumption
>> by Emacs.
>>
>> >> Some people may prefer saying "yes" to saying "why".
>> >
>> > Likewise.
>>
>> "why" is phonetically the same as "y".  Which means that it's likely
>> harder to generate just "y" from voice than "yes".
>>
>> --
>> David Kastrup
>>
>

[-- Attachment #2: Type: text/html, Size: 4808 bytes --]

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Fri, 04 Sep 2015 20:39:22 +0200
> Cc: dgutov@yandex.ru, bruce.connor.am@gmail.com, emacs-devel@gnu.org,
> 	schwab@linux-m68k.org, monnier@iro.umontreal.ca,
> 	kaushal.modi@gmail.com, acm@muc.de, drew.adams@oracle.com
> 
> >> Reliable translation into selection boxes when feeding emacs -batch from
> >> a script?
> >
> > y-or-n-p already does TRT in that case (no dialog boxes in -batch).
> 
> Feeding emacs -batch _from_ a script.  Meaning the script supplies "yes"
> and "no".

That already works, AFAIK.

> >> Predictable behavior when navigating Emacs by voice?
> >
> > I don't see the relevance, please elaborate.
> 
> Same as above.  External input translated into a source for consumption
> by Emacs.

Same as above.

> >> Some people may prefer saying "yes" to saying "why".
> >
> > Likewise.
> 
> "why" is phonetically the same as "y".  Which means that it's likely
> harder to generate just "y" from voice than "yes".

Then it should work already.

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> Date: Fri, 04 Sep 2015 22:47:05 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: dgutov@yandex.ru, bruce.connor.am@gmail.com, emacs-devel@gnu.org,
> 	schwab@linux-m68k.org, monnier@iro.umontreal.ca,
> 	kaushal.modi@gmail.com, acm@muc.de, drew.adams@oracle.com
> 
> > From: David Kastrup <dak@gnu.org>
> > Date: Fri, 04 Sep 2015 20:39:22 +0200
> > Cc: dgutov@yandex.ru, bruce.connor.am@gmail.com, emacs-devel@gnu.org,
> > 	schwab@linux-m68k.org, monnier@iro.umontreal.ca,
> > 	kaushal.modi@gmail.com, acm@muc.de, drew.adams@oracle.com
> > 
> > >> Reliable translation into selection boxes when feeding emacs -batch from
> > >> a script?
> > >
> > > y-or-n-p already does TRT in that case (no dialog boxes in -batch).
> > 
> > Feeding emacs -batch _from_ a script.  Meaning the script supplies "yes"
> > and "no".
> 
> That already works, AFAIK.

I meant it already works if the script supplies "y" or "n", not
literally "yes" and "no".  If you had the latter in mind, then I see
no reason for a script to supply "yes" when it knows that Emacs needs
"y".  But we could, of course, extend y-or-n-p to accept "yes" and
"no" when in batch mode.

IOW, it's a separate issue, whose solution is not necessarily to make
y-or-n-p work as yes-or-no-p.

Re: yes-or-no-p prompt conditionally broken in master?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Fri, 04 Sep 2015 20:39:22 +0200
>> Cc: dgutov@yandex.ru, bruce.connor.am@gmail.com, emacs-devel@gnu.org,
>> 	schwab@linux-m68k.org, monnier@iro.umontreal.ca,
>> 	kaushal.modi@gmail.com, acm@muc.de, drew.adams@oracle.com
>> 
>> >> Reliable translation into selection boxes when feeding emacs -batch from
>> >> a script?
>> >
>> > y-or-n-p already does TRT in that case (no dialog boxes in -batch).
>> 
>> Feeding emacs -batch _from_ a script.  Meaning the script supplies "yes"
>> and "no".
>
> That already works, AFAIK.
>
>> >> Predictable behavior when navigating Emacs by voice?
>> >
>> > I don't see the relevance, please elaborate.
>> 
>> Same as above.  External input translated into a source for consumption
>> by Emacs.
>
> Same as above.
>
>> >> Some people may prefer saying "yes" to saying "why".
>> >
>> > Likewise.
>> 
>> "why" is phonetically the same as "y".  Which means that it's likely
>> harder to generate just "y" from voice than "yes".
>
> Then it should work already.

emacs -batch --eval '(prin1 (y-or-n-p "Yes or no?"))'
Yes or no? (y or n) yes
Please answer y or n.  Yes or no? (y or n) no
Please answer y or n.  Yes or no? (y or n) yes
Please answer y or n.  Yes or no? (y or n) no
Please answer y or n.  Yes or no? (y or n) n
nil

Sometimes I have a hard time figuring out just why people take me for a
ride.  Do they know what they are claiming to be wrong or do they just
find it easier to leave the fact checking to someone else?

-- 
David Kastrup

Re: yes-or-no-p prompt conditionally broken in master?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 04 Sep 2015 22:47:05 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: dgutov@yandex.ru, bruce.connor.am@gmail.com, emacs-devel@gnu.org,
>> 	schwab@linux-m68k.org, monnier@iro.umontreal.ca,
>> 	kaushal.modi@gmail.com, acm@muc.de, drew.adams@oracle.com
>> 
>> > From: David Kastrup <dak@gnu.org>
>> > Date: Fri, 04 Sep 2015 20:39:22 +0200
>> > Cc: dgutov@yandex.ru, bruce.connor.am@gmail.com, emacs-devel@gnu.org,
>> > 	schwab@linux-m68k.org, monnier@iro.umontreal.ca,
>> > 	kaushal.modi@gmail.com, acm@muc.de, drew.adams@oracle.com
>> > 
>> > >> Reliable translation into selection boxes when feeding emacs -batch from
>> > >> a script?
>> > >
>> > > y-or-n-p already does TRT in that case (no dialog boxes in -batch).
>> > 
>> > Feeding emacs -batch _from_ a script.  Meaning the script supplies "yes"
>> > and "no".
>> 
>> That already works, AFAIK.
>
> I meant it already works if the script supplies "y" or "n", not
> literally "yes" and "no".

Let me guess: you checked after posting your reply and followed up (in
overlap to my reply to the original reply).  It hardly makes sense that
you indeed meant it at the time of writing:

>
>> "why" is phonetically the same as "y".  Which means that it's likely
>> harder to generate just "y" from voice than "yes".
>
> Then it should work already.

-- 
David Kastrup

Re: yes-or-no-p prompt conditionally broken in master?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 04 Sep 2015 22:47:05 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: dgutov@yandex.ru, bruce.connor.am@gmail.com, emacs-devel@gnu.org,
>> 	schwab@linux-m68k.org, monnier@iro.umontreal.ca,
>> 	kaushal.modi@gmail.com, acm@muc.de, drew.adams@oracle.com
>> 
>> > From: David Kastrup <dak@gnu.org>
>> > Date: Fri, 04 Sep 2015 20:39:22 +0200
>> > Cc: dgutov@yandex.ru, bruce.connor.am@gmail.com, emacs-devel@gnu.org,
>> > 	schwab@linux-m68k.org, monnier@iro.umontreal.ca,
>> > 	kaushal.modi@gmail.com, acm@muc.de, drew.adams@oracle.com
>> > 
>> > >> Reliable translation into selection boxes when feeding emacs -batch from
>> > >> a script?
>> > >
>> > > y-or-n-p already does TRT in that case (no dialog boxes in -batch).
>> > 
>> > Feeding emacs -batch _from_ a script.  Meaning the script supplies "yes"
>> > and "no".
>> 
>> That already works, AFAIK.
>
> I meant it already works if the script supplies "y" or "n", not
> literally "yes" and "no".  If you had the latter in mind, then I see
> no reason for a script to supply "yes" when it knows that Emacs needs
> "y".

How would the script know which user settings for the proposed
customizable yes-or-no-p behavior options are active when it is used in
a manner reading in the user init file before proceeding?

> But we could, of course, extend y-or-n-p to accept "yes" and "no" when
> in batch mode.
>
> IOW, it's a separate issue, whose solution is not necessarily to make
> y-or-n-p work as yes-or-no-p.

It's not entirely separate since it extends the manners in which Emacs
might "legitimately" behave.  Customizable options usually don't fall
into "if it breaks, you get to keep the pieces" category.

-- 
David Kastrup

Re: yes-or-no-p prompt conditionally broken in master?

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > (and I expect this aliasing to always work, because the identity of
 > > the APIs is not accidental).
 > 
 > It might indeed always work, but you shouldn't expect that.

From long experience with Emacs, I have to agree that I can't expect
that -- Emacs sometimes lacks respect for orthogonality of APIs (and
UIs, for that matter).  I also agree with Andreas -- I *should* be
*able* to expect that, and it's a good thing for developers to
anticipate and cater to such expectations.

Re: yes-or-no-p prompt conditionally broken in master?

[Stephen J. Turnbull]

Marcin Borkowski writes:
 > On 2015-09-04, at 11:26, Andreas Schwab <schwab@linux-m68k.org> wrote:
 > > Eli Zaretskii <eliz@gnu.org> writes:
 > >
 > >> Any objections to removing yes-or-no-p (with a defalias for backward
 > >> compatibility, of course) and making y-or-n-p serve both duties,
 > >> controlled by some defcustom?
 > >
 > > That doesn't make sense.  They implement different intented
 > > meaning.

The API would need an argument to control it, and in that sense Eli's
proposal is incomplete.  But it makes sense.

 > +1.  They serve different purposes, and they are both needed.

Both semantics are useful, but they serve the same basic purpose.
There's no good reason for having separate APIs, and it's arguable
that maintaining parallel syntax is sufficient reason for unifying as
a single API, given some core developers' aversion to making promises
about consistency of API.

If I were a "I never saw a behavior that I wouldn't make optional"
fanatic, I'd go on to propose an elaborate API and UI, where the main
function would be

    (defun user-confirmation (prompt oracle)   ; not optional!!
      "The docstring is left as an exercise for the reader."
      (if (functionp oracle)
          (funcall oracle prompt)
        t))                ; #### too fragile in the face of typos?

And the options would be stuff like:

    (defcustom user-confirmation-fatfinger-fandango 'y-or-n-p)
    (defcustom user-confirmation-irreversible-change 'yes-or-no-p)
    (defcustom user-confirmation-truly-timid-user "don't bother me!")
    (defcustom user-confirmation-authenticate 'reauthenticate-user)

But I really don't see the need for a unification or generalization.
The two levels are enough.  Security-relevant cases will probably
have their own mechanisms anyway, and nobody would be very likely to
want to set truly-timid-user to anything other than "don't bug me".

Nor can I see any reason why the syntax would need to diverge.  Just
promise that (defalias 'yes-or-no-p 'y-or-n-p) will work forever.  If
necessary to change one or the other's signature, add dummy arguments
to the function whose implementation doesn't change.

Re: yes-or-no-p prompt conditionally broken in master?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: dgutov@yandex.ru,  bruce.connor.am@gmail.com,  emacs-devel@gnu.org,  schwab@linux-m68k.org,  monnier@iro.umontreal.ca,  kaushal.modi@gmail.com,  acm@muc.de,  drew.adams@oracle.com
> Date: Fri, 04 Sep 2015 22:04:27 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I meant it already works if the script supplies "y" or "n", not
> > literally "yes" and "no".  If you had the latter in mind, then I see
> > no reason for a script to supply "yes" when it knows that Emacs needs
> > "y".
> 
> How would the script know which user settings for the proposed
> customizable yes-or-no-p behavior options are active when it is used in
> a manner reading in the user init file before proceeding?

The issue at hand was whether we need to have a way to make y-or-n-p
behave like yes-or-no-p.  So the scripts we are supposed to discuss
are those that invoke y-or-n-p, whose behavior is not subject to
customizations under my proposal.

So the scripts should always supply y followed by a newline.

> > But we could, of course, extend y-or-n-p to accept "yes" and "no" when
> > in batch mode.
> >
> > IOW, it's a separate issue, whose solution is not necessarily to make
> > y-or-n-p work as yes-or-no-p.
> 
> It's not entirely separate since it extends the manners in which Emacs
> might "legitimately" behave.

In that regard, it indeed is not separate.  But the number of manners
in which Emacs might behave is truly infinite, so IMO it isn't useful
to lump issues together just because they belong to that wide class.

The problem you describe with scripts that feed Emacs with "yes" when
they should have fed it with "y", if it exists, is already here.  We
should have heard about it by now.  If, for some reason, we didn't and
will hear later, we could always extend y-or-n-p as I mentioned above.

IOW, it's a separate issue because its reasons and solution are
independent of the one which triggered this thread.

Re: yes-or-no-p prompt conditionally broken in master?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: dgutov@yandex.ru, bruce.connor.am@gmail.com,
>> emacs-devel@gnu.org, schwab@linux-m68k.org,
>> monnier@iro.umontreal.ca, kaushal.modi@gmail.com, acm@muc.de,
>> drew.adams@oracle.com
>> Date: Fri, 04 Sep 2015 22:04:27 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I meant it already works if the script supplies "y" or "n", not
>> > literally "yes" and "no".  If you had the latter in mind, then I see
>> > no reason for a script to supply "yes" when it knows that Emacs needs
>> > "y".
>> 
>> How would the script know which user settings for the proposed
>> customizable yes-or-no-p behavior options are active when it is used in
>> a manner reading in the user init file before proceeding?
>
> The issue at hand was whether we need to have a way to make y-or-n-p
> behave like yes-or-no-p.  So the scripts we are supposed to discuss
> are those that invoke y-or-n-p, whose behavior is not subject to
> customizations under my proposal.
>
> So the scripts should always supply y followed by a newline.
>
>> > But we could, of course, extend y-or-n-p to accept "yes" and "no" when
>> > in batch mode.
>> >
>> > IOW, it's a separate issue, whose solution is not necessarily to make
>> > y-or-n-p work as yes-or-no-p.
>> 
>> It's not entirely separate since it extends the manners in which Emacs
>> might "legitimately" behave.
>
> In that regard, it indeed is not separate.  But the number of manners
> in which Emacs might behave is truly infinite,

Not with regard to discrete-valued customizable options.

-- 
David Kastrup