Unexpected behavior of format-number with format-prompt

Unexpected behavior of format-number with format-prompt

[Joseph Turner]

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

When used with `read-string' (and other read-* functions),
`format-prompt' DTRT:

(let ((default "foo"))
  (read-string (format-prompt "Read" default) default))

The prompt looks like: "Read (default foo): "

However, `read-number' adds its own default argument:

(let ((default 1))
  (read-number (format-prompt "Read" default) default))

Prompt looks like: "Read (default 1) (default 1): "

This patch makes the behavior of `read-number' consistent with other
read-* functions:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Don-t-insert-DEFAULT-value-into-prompt.patch --]
[-- Type: text/x-diff, Size: 1361 bytes --]

From f42643852249a07acf9181aca37af351ff52bb5b Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 6 Nov 2024 11:54:31 -0800
Subject: [PATCH] Don't insert DEFAULT value into prompt

* lisp/subr.el (read-number): Don't insert default value into prompt.
---
 lisp/subr.el | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/lisp/subr.el b/lisp/subr.el
index e630087b68f..aa37066609c 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3424,20 +3424,12 @@ read-number-history
 (defun read-number (prompt &optional default hist)
   "Read a numeric value in the minibuffer, prompting with PROMPT.
 DEFAULT specifies a default value to return if the user just types RET.
-The value of DEFAULT is inserted into PROMPT.
 HIST specifies a history list variable.  See `read-from-minibuffer'
 for details of the HIST argument.
 
 This function is used by the `interactive' code letter \"n\"."
   (let ((n nil)
 	(default1 (if (consp default) (car default) default)))
-    (when default1
-      (setq prompt
-	    (if (string-match "\\(\\):[ \t]*\\'" prompt)
-		(replace-match (format minibuffer-default-prompt-format default1) t t prompt 1)
-	      (replace-regexp-in-string "[ \t]*\\'"
-					(format minibuffer-default-prompt-format default1)
-					prompt t t))))
     (while
 	(progn
 	  (let ((str (read-from-minibuffer
-- 
2.46.0


[-- Attachment #3: Type: text/plain, Size: 328 bytes --]


If this patch is acceptable, I'll update NEWS and submit patches to make
`read-number' calls in core to use `format-prompt'.

I understand that such a breaking change may not be acceptable since it
affects external packages as well.  In that case, this patch documents
the collision between `read-number' and `format-prompt':


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0001-Document-behavior-of-format-prompt-with-read-number.patch --]
[-- Type: text/x-diff, Size: 1066 bytes --]

From 0f3c690650e30201c725186bff3b91ef8fa4ee19 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Wed, 6 Nov 2024 11:53:42 -0800
Subject: [PATCH] Document behavior of format-prompt with read-number

* doc/lispref/minibuf.texi (Text from Minibuffer): Update info manual.
---
 doc/lispref/minibuf.texi | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/doc/lispref/minibuf.texi b/doc/lispref/minibuf.texi
index c5b9176d628..8bb53f6d831 100644
--- a/doc/lispref/minibuf.texi
+++ b/doc/lispref/minibuf.texi
@@ -491,6 +491,10 @@ Text from Minibuffer
 
 If @var{default} is @code{nil}, there is no default value, and
 therefore no ``default value'' string is included in the result value.
+For historical reasons, @code{read-number} always adds its
+@code{default} argument to its prompt, so the @var{default} argument of
+@code{format-prompt} should be @code{nil} when its return value will be
+passed to @code{read-number}.
 If @var{default} is a non-@code{nil} list, the first element of the
 list is used in the prompt.
 
-- 
2.46.0


[-- Attachment #5: Type: text/plain, Size: 17 bytes --]


Thanks!

Joseph

Re: Unexpected behavior of format-number with format-prompt

[Eli Zaretskii]

> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Wed, 06 Nov 2024 12:06:02 -0800
> 
> When used with `read-string' (and other read-* functions),
> `format-prompt' DTRT:
> 
> (let ((default "foo"))
>   (read-string (format-prompt "Read" default) default))
> 
> The prompt looks like: "Read (default foo): "
> 
> However, `read-number' adds its own default argument:
> 
> (let ((default 1))
>   (read-number (format-prompt "Read" default) default))
> 
> Prompt looks like: "Read (default 1) (default 1): "
> 
> This patch makes the behavior of `read-number' consistent with other
> read-* functions:

Thanks.

First, this should have been sent to our issue tracker, via
report-emacs-bug or submit-emacs-patch.

More to the point: we cannot possibly change the behavior of
read-number in such a backward-incompatible way.  Especially since
this behavior is old, and explicitly called out in the doc string.  It
is perhaps unfortunate that read-number behaves differently in this
manner, but I'm afraid we will have to live with this.

Re: Unexpected behavior of format-number with format-prompt

[Joseph Turner]

On November 6, 2024 11:36:42 PM PST, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Wed, 06 Nov 2024 12:06:02 -0800
>> 
>> When used with `read-string' (and other read-* functions),
>> `format-prompt' DTRT:
>> 
>> (let ((default "foo"))
>>   (read-string (format-prompt "Read" default) default))
>> 
>> The prompt looks like: "Read (default foo): "
>> 
>> However, `read-number' adds its own default argument:
>> 
>> (let ((default 1))
>>   (read-number (format-prompt "Read" default) default))
>> 
>> Prompt looks like: "Read (default 1) (default 1): "
>> 
>> This patch makes the behavior of `read-number' consistent with other
>> read-* functions:
>
>Thanks.
>
>First, this should have been sent to our issue tracker, via
>report-emacs-bug or submit-emacs-patch.

Got it.  Shall I do this now?

>More to the point: we cannot possibly change the behavior of
>read-number in such a backward-incompatible way.  Especially since
>this behavior is old, and explicitly called out in the doc string.  It
>is perhaps unfortunate that read-number behaves differently in this
>manner, but I'm afraid we will have to live with this.

That makes sense.  Can we apply the info manual change?

Re: Unexpected behavior of format-number with format-prompt

[Eli Zaretskii]

> Date: Wed, 06 Nov 2024 23:44:00 -0800
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> CC: emacs-devel@gnu.org
> 
> >First, this should have been sent to our issue tracker, via
> >report-emacs-bug or submit-emacs-patch.
> 
> Got it.  Shall I do this now?

Too late.  Please remember this for the future.

> >More to the point: we cannot possibly change the behavior of
> >read-number in such a backward-incompatible way.  Especially since
> >this behavior is old, and explicitly called out in the doc string.  It
> >is perhaps unfortunate that read-number behaves differently in this
> >manner, but I'm afraid we will have to live with this.
> 
> That makes sense.  Can we apply the info manual change?

I think this change should be in the doc string of read-number, not in
the manual.  One reason is that read-number is not documented in the
manual, while the description of this nit logically belongs to it, not
to format-prompt.  (Btw, the same effect could be achieved if
minibuffer-default-prompt-format is bound to the empty string, right?)

Re: Unexpected behavior of format-number with format-prompt

[Joseph Turner]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 06 Nov 2024 23:44:00 -0800
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> CC: emacs-devel@gnu.org
>> 
>> >First, this should have been sent to our issue tracker, via
>> >report-emacs-bug or submit-emacs-patch.
>> 
>> Got it.  Shall I do this now?
>
> Too late.  Please remember this for the future.
>
>> >More to the point: we cannot possibly change the behavior of
>> >read-number in such a backward-incompatible way.  Especially since
>> >this behavior is old, and explicitly called out in the doc string.  It
>> >is perhaps unfortunate that read-number behaves differently in this
>> >manner, but I'm afraid we will have to live with this.
>> 
>> That makes sense.  Can we apply the info manual change?
>
> I think this change should be in the doc string of read-number, not in
> the manual.  One reason is that read-number is not documented in the
> manual, while the description of this nit logically belongs to it, not
> to format-prompt.

I agree.  How about this?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-subr.el-read-number-Document-collision-with-for.patch --]
[-- Type: text/x-diff, Size: 1190 bytes --]

From 29dbfe3436ca93afd195c0e10b2c22d58b22e52c Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Sat, 9 Nov 2024 11:15:25 -0800
Subject: [PATCH] * lisp/subr.el (read-number): Document collision with
 format-prompt

---
 lisp/subr.el | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lisp/subr.el b/lisp/subr.el
index b56512aac05..6472c9d6916 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3424,9 +3424,10 @@ read-number-history
 (defun read-number (prompt &optional default hist)
   "Read a numeric value in the minibuffer, prompting with PROMPT.
 DEFAULT specifies a default value to return if the user just types RET.
-The value of DEFAULT is inserted into PROMPT.
-HIST specifies a history list variable.  See `read-from-minibuffer'
-for details of the HIST argument.
+For historical reasons, the value of DEFAULT is always inserted into
+PROMPT, so it's recommended to use `format' instead of `format-prompt'
+to generate PROMPT.  HIST specifies a history list variable.  See
+`read-from-minibuffer' for details of the HIST argument.
 
 This function is used by the `interactive' code letter \"n\"."
   (let ((n nil)
-- 
2.46.0


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


> (Btw, the same effect could be achieved if
> minibuffer-default-prompt-format is bound to the empty string, right?)

format-prompt also uses minibuffer-default-prompt-format internally, so
minibuffer-default-prompt-format would need to be to nil for the
read-number call but not the format-prompt call.

I suppose you could do this, but IMO the meaning is not all that clear:

(let ((default-prompt (format-prompt "Read number" "three"))
      (minibuffer-default-prompt-format ""))
  (read-number default-prompt 3))

Thanks!

Joseph

Re: Unexpected behavior of format-number with format-prompt

[Eli Zaretskii]

> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Cc: emacs-devel@gnu.org
> Date: Sat, 09 Nov 2024 11:18:50 -0800
> 
> > I think this change should be in the doc string of read-number, not in
> > the manual.  One reason is that read-number is not documented in the
> > manual, while the description of this nit logically belongs to it, not
> > to format-prompt.
> 
> I agree.  How about this?

LGTM, please install on the emacs-30 release branch.

Re: Unexpected behavior of format-number with format-prompt

[Stephen Berman]

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

On Thu, 07 Nov 2024 09:36:42 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Wed, 06 Nov 2024 12:06:02 -0800
>>
>> When used with `read-string' (and other read-* functions),
>> `format-prompt' DTRT:
>>
>> (let ((default "foo"))
>>   (read-string (format-prompt "Read" default) default))
>>
>> The prompt looks like: "Read (default foo): "
>>
>> However, `read-number' adds its own default argument:
>>
>> (let ((default 1))
>>   (read-number (format-prompt "Read" default) default))
>>
>> Prompt looks like: "Read (default 1) (default 1): "
>>
>> This patch makes the behavior of `read-number' consistent with other
>> read-* functions:
>
> Thanks.
>
> First, this should have been sent to our issue tracker, via
> report-emacs-bug or submit-emacs-patch.
>
> More to the point: we cannot possibly change the behavior of
> read-number in such a backward-incompatible way.  Especially since
> this behavior is old, and explicitly called out in the doc string.  It
> is perhaps unfortunate that read-number behaves differently in this
> manner, but I'm afraid we will have to live with this.

Maybe something like the attached patch is acceptable?  With it,
evaluating each of the following prompts with "Enter (default 42): "

(read-number "Enter: " 42)
(read-number (format-prompt "Enter" 42))
(read-number (format-prompt "Enter" 42) 42)

Steve Berman

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: read-number patch --]
[-- Type: text/x-patch, Size: 1104 bytes --]

diff --git a/lisp/subr.el b/lisp/subr.el
index e630087b68f..8dcaef08b65 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3432,12 +3432,18 @@ read-number
   (let ((n nil)
 	(default1 (if (consp default) (car default) default)))
     (when default1
-      (setq prompt
-	    (if (string-match "\\(\\):[ \t]*\\'" prompt)
-		(replace-match (format minibuffer-default-prompt-format default1) t t prompt 1)
-	      (replace-regexp-in-string "[ \t]*\\'"
-					(format minibuffer-default-prompt-format default1)
-					prompt t t))))
+      ;; If PROMPT uses `format-prompt', don't duplicate DEFAULT in
+      ;; the prompt string.
+      (if (string-match (regexp-quote
+			 (format minibuffer-default-prompt-format default1))
+			prompt)
+	  (setq default1 nil)
+        (setq prompt
+	      (if (string-match "\\(\\):[ \t]*\\'" prompt)
+		  (replace-match (format minibuffer-default-prompt-format default1) t t prompt 1)
+	        (replace-regexp-in-string "[ \t]*\\'"
+					  (format minibuffer-default-prompt-format default1)
+					  prompt t t)))))
     (while
 	(progn
 	  (let ((str (read-from-minibuffer

Re: Unexpected behavior of format-number with format-prompt

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Joseph Turner <joseph@breatheoutbreathe.in>,  emacs-devel@gnu.org
> Date: Thu, 07 Nov 2024 14:50:27 +0100
> 
> > More to the point: we cannot possibly change the behavior of
> > read-number in such a backward-incompatible way.  Especially since
> > this behavior is old, and explicitly called out in the doc string.  It
> > is perhaps unfortunate that read-number behaves differently in this
> > manner, but I'm afraid we will have to live with this.
> 
> Maybe something like the attached patch is acceptable?  With it,
> evaluating each of the following prompts with "Enter (default 42): "
> 
> (read-number "Enter: " 42)
> (read-number (format-prompt "Enter" 42))
> (read-number (format-prompt "Enter" 42) 42)

This assumes that using the same format as
minibuffer-default-prompt-format necessarily means that format-prompt
is being used.  I'm not sure we can rely on that, it's too ad-hoc.

Re: Unexpected behavior of format-number with format-prompt

[Stephen Berman]

On Thu, 07 Nov 2024 16:47:40 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Joseph Turner <joseph@breatheoutbreathe.in>,  emacs-devel@gnu.org
>> Date: Thu, 07 Nov 2024 14:50:27 +0100
>>
>> > More to the point: we cannot possibly change the behavior of
>> > read-number in such a backward-incompatible way.  Especially since
>> > this behavior is old, and explicitly called out in the doc string.  It
>> > is perhaps unfortunate that read-number behaves differently in this
>> > manner, but I'm afraid we will have to live with this.
>>
>> Maybe something like the attached patch is acceptable?  With it,
>> evaluating each of the following prompts with "Enter (default 42): "
>>
>> (read-number "Enter: " 42)
>> (read-number (format-prompt "Enter" 42))
>> (read-number (format-prompt "Enter" 42) 42)
>
> This assumes that using the same format as
> minibuffer-default-prompt-format necessarily means that format-prompt
> is being used.  I'm not sure we can rely on that, it's too ad-hoc.

The patch itself does not assume format-prompt but only checks whether
the prompt uses minibuffer-default-prompt-format (which format-prompt
does); the following also prompt with "Enter (default 42): ":

(read-number (concat "Enter"
                     (format minibuffer-default-prompt-format 42)
                     ": "))

(read-number (concat "Enter:"
                     (format minibuffer-default-prompt-format 42)
                     ": ")
             42)

So the reference to format-prompt in the comment I added is misleading
and should be either removed or revised, e.g.: "If PROMPT uses
`minibuffer-default-prompt-format' (as e.g. with `format-prompt'), don't
duplicate DEFAULT in the prompt string."

Steve Berman

Re: Unexpected behavior of format-number with format-prompt

[Joseph Turner]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Thu, 07 Nov 2024 16:47:40 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Cc: Joseph Turner <joseph@breatheoutbreathe.in>,  emacs-devel@gnu.org
>>> Date: Thu, 07 Nov 2024 14:50:27 +0100
>>>
>>> > More to the point: we cannot possibly change the behavior of
>>> > read-number in such a backward-incompatible way.  Especially since
>>> > this behavior is old, and explicitly called out in the doc string.  It
>>> > is perhaps unfortunate that read-number behaves differently in this
>>> > manner, but I'm afraid we will have to live with this.
>>>
>>> Maybe something like the attached patch is acceptable?  With it,
>>> evaluating each of the following prompts with "Enter (default 42): "
>>>
>>> (read-number "Enter: " 42)
>>> (read-number (format-prompt "Enter" 42))
>>> (read-number (format-prompt "Enter" 42) 42)
>>
>> This assumes that using the same format as
>> minibuffer-default-prompt-format necessarily means that format-prompt
>> is being used.  I'm not sure we can rely on that, it's too ad-hoc.
>
> The patch itself does not assume format-prompt but only checks whether
> the prompt uses minibuffer-default-prompt-format (which format-prompt
> does); the following also prompt with "Enter (default 42): ":
>
> (read-number (concat "Enter"
>                      (format minibuffer-default-prompt-format 42)
>                      ": "))
>
> (read-number (concat "Enter:"
>                      (format minibuffer-default-prompt-format 42)
>                      ": ")
>              42)
>
> So the reference to format-prompt in the comment I added is misleading
> and should be either removed or revised, e.g.: "If PROMPT uses
> `minibuffer-default-prompt-format' (as e.g. with `format-prompt'), don't
> duplicate DEFAULT in the prompt string."

I like your idea, but the DEFAULT argument passed to `format-prompt' may
be different from the DEFAULT argument passed to `read-number', so the
regex may not match.  For example,

(read-number (format-prompt "Read number" "three") 3)

would still prompt with

Read number (default three) (default 3):

[ Also /s/string-match/string-match-p ]

I think we're better off documenting the idiosyncrasy in the
`read-number' docstring as Eli suggested.

Thanks!

Joseph

Re: Unexpected behavior of format-number with format-prompt

[Stephen Berman]

On Sat, 09 Nov 2024 11:02:58 -0800 Joseph Turner <joseph@breatheoutbreathe.in> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Thu, 07 Nov 2024 16:47:40 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>>> From: Stephen Berman <stephen.berman@gmx.net>
>>>> Cc: Joseph Turner <joseph@breatheoutbreathe.in>,  emacs-devel@gnu.org
>>>> Date: Thu, 07 Nov 2024 14:50:27 +0100
>>>>
>>>> > More to the point: we cannot possibly change the behavior of
>>>> > read-number in such a backward-incompatible way.  Especially since
>>>> > this behavior is old, and explicitly called out in the doc string.  It
>>>> > is perhaps unfortunate that read-number behaves differently in this
>>>> > manner, but I'm afraid we will have to live with this.
>>>>
>>>> Maybe something like the attached patch is acceptable?  With it,
>>>> evaluating each of the following prompts with "Enter (default 42): "
>>>>
>>>> (read-number "Enter: " 42)
>>>> (read-number (format-prompt "Enter" 42))
>>>> (read-number (format-prompt "Enter" 42) 42)
>>>
>>> This assumes that using the same format as
>>> minibuffer-default-prompt-format necessarily means that format-prompt
>>> is being used.  I'm not sure we can rely on that, it's too ad-hoc.
>>
>> The patch itself does not assume format-prompt but only checks whether
>> the prompt uses minibuffer-default-prompt-format (which format-prompt
>> does); the following also prompt with "Enter (default 42): ":
>>
>> (read-number (concat "Enter"
>>                      (format minibuffer-default-prompt-format 42)
>>                      ": "))
>>
>> (read-number (concat "Enter:"
>>                      (format minibuffer-default-prompt-format 42)
>>                      ": ")
>>              42)
>>
>> So the reference to format-prompt in the comment I added is misleading
>> and should be either removed or revised, e.g.: "If PROMPT uses
>> `minibuffer-default-prompt-format' (as e.g. with `format-prompt'), don't
>> duplicate DEFAULT in the prompt string."
>
> I like your idea, but the DEFAULT argument passed to `format-prompt' may
> be different from the DEFAULT argument passed to `read-number', so the
> regex may not match.  For example,
>
> (read-number (format-prompt "Read number" "three") 3)
>
> would still prompt with
>
> Read number (default three) (default 3):

In all uses of format-prompt I checked in the Emacs sources, the same
value is passed to the DEFAULT argument of both format-prompt and its
caller (e.g. read-string).  Do you have a realistic use case
(i.e. discounting willfully misleading or mischievous programming) in
mind where this is not so?  I couldn't find or come up with one, but
maybe I missed it or didn't think hard enough.

> [ Also /s/string-match/string-match-p ]

I just followed the current code in `read-number', which already uses
`string-match'.  Perhaps that should be changed regardless of my patch?

> I think we're better off documenting the idiosyncrasy in the
> `read-number' docstring as Eli suggested.

That's certainly the path of least risk, though I can't think of a
plausible use where my patch would result in duplication in the prompt
string.

Steve Berman

Re: Unexpected behavior of format-number with format-prompt

[Joseph Turner]

On November 9, 2024 1:51:24 PM PST, Stephen Berman <stephen.berman@gmx.net> wrote:
>In all uses of format-prompt I checked in the Emacs sources, the same
>value is passed to the DEFAULT argument of both format-prompt and its
>caller (e.g. read-string).  Do you have a realistic use case
>(i.e. discounting willfully misleading or mischievous programming) in
>mind where this is not so?  I couldn't find or come up with one, but
>maybe I missed it or didn't think hard enough.
>
>> [ Also /s/string-match/string-match-p ]
>
>I just followed the current code in `read-number', which already uses
>`string-match'.  Perhaps that should be changed regardless of my patch?

I think so.

>> I think we're better off documenting the idiosyncrasy in the
>> `read-number' docstring as Eli suggested.
>
>That's certainly the path of least risk, though I can't think of a
>plausible use where my patch would result in duplication in the prompt
>string.

The patch works if you specify the prompt with format-prompt, but if you try to roll your own prompt like (read-number (format "Type number (DEFAULT %s): " default) default) then confusingly there's duplication.

Maybe you want to display the default number in a different base in the prompt.

Maybe you want the prompt to be user-defined.

My desire is for simplicity.

However if the maintainers approve it, I'm happy to see it included and documented.

In any case, I appreciate your thinking :)

Cheers,

Joseph

Re: Unexpected behavior of format-number with format-prompt

[Stephen Berman]

On Sat, 09 Nov 2024 19:55:31 -0800 Joseph Turner <joseph@breatheoutbreathe.in> wrote:

> On November 9, 2024 1:51:24 PM PST, Stephen Berman <stephen.berman@gmx.net> wrote:
>>In all uses of format-prompt I checked in the Emacs sources, the same
>>value is passed to the DEFAULT argument of both format-prompt and its
>>caller (e.g. read-string).  Do you have a realistic use case
>>(i.e. discounting willfully misleading or mischievous programming) in
>>mind where this is not so?  I couldn't find or come up with one, but
>>maybe I missed it or didn't think hard enough.
>>
>>> [ Also /s/string-match/string-match-p ]
>>
>>I just followed the current code in `read-number', which already uses
>>`string-match'.  Perhaps that should be changed regardless of my patch?
>
> I think so.

Be my guest :-)

>>> I think we're better off documenting the idiosyncrasy in the
>>> `read-number' docstring as Eli suggested.
>>
>>That's certainly the path of least risk, though I can't think of a
>>plausible use where my patch would result in duplication in the prompt
>>string.
>
> The patch works if you specify the prompt with format-prompt, but if you try
> to roll your own prompt like (read-number (format "Type number (DEFAULT %s): "
> default) default) then confusingly there's duplication.
>
> Maybe you want to display the default number in a different base in the prompt.
>
> Maybe you want the prompt to be user-defined.
>
> My desire is for simplicity.

I thought the motivation of your OP was a more uniform implementation of
the *-read-* functions' prompt using format-patch; that's also a kind of
simplicity, no?

> However if the maintainers approve it, I'm happy to see it included and documented.

I think that ship won't sail :-)

> In any case, I appreciate your thinking :)

Thanks.

> Cheers,
>
> Joseph

Steve Berman

Re: Unexpected behavior of format-number with format-prompt

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 09 Nov 2024 22:51:24 +0100
> 
> > I think we're better off documenting the idiosyncrasy in the
> > `read-number' docstring as Eli suggested.
> 
> That's certainly the path of least risk, though I can't think of a
> plausible use where my patch would result in duplication in the prompt
> string.

Maybe so, but it's just too kludgey to my palate, sorry.

Re: Unexpected behavior of format-number with format-prompt

[Stephen Berman]

On Sun, 10 Nov 2024 07:46:04 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Sat, 09 Nov 2024 22:51:24 +0100
>>
>> > I think we're better off documenting the idiosyncrasy in the
>> > `read-number' docstring as Eli suggested.
>>
>> That's certainly the path of least risk, though I can't think of a
>> plausible use where my patch would result in duplication in the prompt
>> string.
>
> Maybe so, but it's just too kludgey to my palate, sorry.

Understood, and no need to be sorry, I'm not that disappointed :-)

Steve Berman