GNU bug report logs - #70725
29.3; dired-do-touch completion

Previous Next

Full log

Message #64 received at 70725 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Thierry Volpiatto <thievol <at> posteo.net>
Cc: christopher <at> librehacker.com, Eli Zaretskii <eliz <at> gnu.org>,
 schwab <at> linux-m68k.org, 70725 <at> debbugs.gnu.org
Subject: Re: bug#70725: 29.3; dired-do-touch completion
Date: Tue, 21 May 2024 20:22:51 +0300

>>>>>> > 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.