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