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

Previous Next

Full log

View this message in rfc822 format

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

[Message part 1 (text/plain, inline)]

Juri Linkov <juri <at> linkov.net> writes:

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

In why returning an empty string fix the issue? We are now back at
initial point, no?

-- 
Thierry

[signature.asc (application/pgp-signature, inline)]

Previous Next

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