emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63399: closed (28.2; Documentation for yes-or-no-p wrong/different b


From: GNU bug Tracking System
Subject: bug#63399: closed (28.2; Documentation for yes-or-no-p wrong/different between docstring and lispref)
Date: Fri, 12 May 2023 10:50:02 +0000

Your message dated Fri, 12 May 2023 12:49:13 +0200
with message-id <87fs81q0ye.fsf@gmx.de>
and subject line Re: bug#63399: 28.2; Documentation for yes-or-no-p 
wrong/different between docstring and lispref
has caused the debbugs.gnu.org bug report #63399,
regarding 28.2; Documentation for yes-or-no-p wrong/different between docstring 
and lispref
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
63399: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63399
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 28.2; Documentation for yes-or-no-p wrong/different between docstring and lispref Date: Tue, 09 May 2023 20:35:20 +0000 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
The documentation for yes-or-no-p in Emacs 28.2 reads:

| yes-or-no-p is a built-in function in ‘C source code’.

| (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; ‘yes-or-no-p’
| adds "(yes or no) " to it.  It does not need to end in space, but if
| it does up to one space will be removed.

| […]

This is wrong: (yes-or-no-p "Prompt? ") gives the prompt
"Prompt? (yes or no) ", but according to the docstring it
should be "Prompt?(yes or no) ".

With the big caveat that I have never looked deeper at
Emacs's C code, the source in src/fns.c does not appear to
change the prompt given as an argument in any way, but just
append yes-or-no-prompt to it.

Also, (elisp) Yes-or-No Queries reads (since 7f53446a10ea;
doc/lispref/minibuf.texi):

| […]

|      Here is an example:

|           (yes-or-no-p "Do you really want to remove everything?")

|           ;; After evaluation of the preceding expression,
|           ;;   the following prompt appears,
|           ;;   with an empty minibuffer:

|           ---------- Buffer: minibuffer ----------
|           Do you really want to remove everything? (yes or no)
|           ---------- Buffer: minibuffer ----------

| […]

This is not the actual result: (yes-or-no-p "Do you really
want to remove everything?") gives the prompt "Do you really
want to remove everything?(yes or no) ", i. e., the space
before the parenthesis is missing.

Finally, the behaviour is different when using
use-short-answers:

| (yes-or-no-p "Prompt?")

gives "Prompt?(yes or no) ", while:

| (let ((use-short-answers t)) (yes-or-no-p "Prompt?"))

gives "Prompt? (y or n) ".



--- End Message ---
--- Begin Message --- Subject: Re: bug#63399: 28.2; Documentation for yes-or-no-p wrong/different between docstring and lispref Date: Fri, 12 May 2023 12:49:13 +0200 User-agent: Gnus/5.13 (Gnus v5.13)
Version: 30.1

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> > But there's no difference if the prompt ends in a space.
>>
>> Yes. It is just a convenience change, and there's code in the wild which
>> doesn't use a trailing space in the propmpt, when calling
>> yes-or-no-p. What would be wrong with my patch? I don't see that it
>> hurts.
>
> I'm sure something will come up.  It isn't an accident that we have
> danced around this more than once in the past.
>
> But if you insist, please install on master, and let's see whose gray
> hair is more right...

I've pushed this to master. In NEWS.28, we have

--8<---------------cut here---------------start------------->8---
** 'yes-or-no-p' and 'y-or-n-p' PROMPT parameter no longer needs trailing space.
In other words, the prompt can now end with "?" instead of "? ".  This
has been the case since Emacs 24.4 but was not announced or documented
until now.  (Checkdoc has also been updated to accept this convention.)
--8<---------------cut here---------------end--------------->8---

So this is the intended bahavior, and the patch is just a bug fix.

Closing this report.

Best regards, Michael.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]