From: Juri Linkov <juri@linkov.net>
To: Thierry Volpiatto <thievol@posteo.net>
Cc: christopher@librehacker.com, Eli Zaretskii <eliz@gnu.org>,
schwab@linux-m68k.org, 70725@debbugs.gnu.org
Subject: bug#70725: 29.3; dired-do-touch completion
Date: Tue, 21 May 2024 20:22:51 +0300 [thread overview]
Message-ID: <86r0dvkrkk.fsf@mail.linkov.net> (raw)
In-Reply-To: <87wmnn5j6g.fsf@posteo.net> (Thierry Volpiatto's message of "Tue, 21 May 2024 14:33:11 +0000")
>>>>>> > However this doesn't explain why dired-do-touch uses a completing-read
>>>>>>
>>>>>> Indeed, this was an oversight. Here is the patch
>>>>>> that replaces 'completing-read' with 'read-string':
>>>>>
>>>>> Thierry, is this solution okay with you?
>>>>
>>>> This fix one issue,
>>>
>>> Thanks, so I pushed the fix.
>>
>> Thanks.
>>
>>>> but default is still wrong IMHO:
>>>>
>>>> When pressing RET with an empty prompt the value is different than what
>>>> is inserted in minibuffer with M-n. Why do we bother setting the
>>>> timesamp at the exact time when pressing RET instead of when pressing
>>>> "T", I mean user would consider the timestamp is set once "T" is
>>>> pressed, with this the behavior would be consistent with RET and M-n and
>>>> the code much simpler.
>>>
>>> There is no need to make the value used by RET and the value inserted by M-n
>>> consistent in 100% of cases.
>>
>> Sorry but I disagree on this.
>
> Same question as with previous issue:
>
> How do I guess (as a third party package maintainer) what DEFAULT is if
> you do such things in Emacs?
>
> We had a similar bug recently where a completing-read was specifying the
> default in prompt (with format-prompt) but the DEFAULT arg was not
> provided, instead DEFAULT was computed later in the function... How do I
> guess what DEFAULT is in such cases? From the prompt? This is not a
> valid solution, like this issue prove.
The docstring of 'read-string' says:
Fourth arg DEFAULT-VALUE is the default value or the list of default values.
If non-nil, it is used for history commands, and as the value (or the first
element of the list of default values) to return if the user enters the
empty string.
So it never returns an empty string. It always returns the default value
that is quite confusing in this case.
OTOH, the docstring of 'read-from-minibuffer' says:
Sixth arg DEFAULT-VALUE, if non-nil, should be a string, which is used
as the default to read if READ is non-nil and the user enters
empty input. But if READ is nil, this function does _not_ return
DEFAULT-VALUE for empty input! Instead, it returns the empty string.
Unlike 'read-string', 'read-from-minibuffer' does not return
the default value for empty input.
So indeed it would be clearer to use 'read-from-minibuffer'
instead of 'read-string' to return an empty string for RET.
This is now fixed as well.
next prev parent reply other threads:[~2024-05-21 17:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 19:51 bug#70725: 29.3; dired-do-touch completion Christopher Howard
2024-05-03 4:55 ` Thierry Volpiatto
2024-05-03 6:13 ` Eli Zaretskii
2024-05-03 7:10 ` Thierry Volpiatto
2024-05-04 11:43 ` Eli Zaretskii
2024-05-04 12:31 ` Thierry Volpiatto
2024-05-05 6:46 ` Juri Linkov
2024-05-06 5:40 ` Thierry Volpiatto
2024-05-06 6:50 ` Juri Linkov
2024-05-06 10:18 ` Thierry Volpiatto
2024-05-06 11:35 ` Andreas Schwab
2024-05-06 12:25 ` Thierry Volpiatto
2024-05-07 16:48 ` Juri Linkov
2024-05-18 8:43 ` Eli Zaretskii
2024-05-18 15:46 ` Thierry Volpiatto
2024-05-21 6:20 ` Juri Linkov
2024-05-21 13:04 ` Thierry Volpiatto
2024-05-21 14:33 ` Thierry Volpiatto
2024-05-21 17:22 ` Juri Linkov [this message]
2024-05-21 20:11 ` Thierry Volpiatto
2024-05-22 4:31 ` Thierry Volpiatto
2024-05-22 6:06 ` Juri Linkov
2024-05-22 17:10 ` Thierry Volpiatto
2024-05-23 15:42 ` Thierry Volpiatto
2024-05-21 16:16 ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86r0dvkrkk.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=70725@debbugs.gnu.org \
--cc=christopher@librehacker.com \
--cc=eliz@gnu.org \
--cc=schwab@linux-m68k.org \
--cc=thievol@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).