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: Wed, 22 May 2024 17:10:42 +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?
>
> No, the accidental completing-read that caused you trouble
> was removed completely, so your problem is solved now.

Yes it is solved, thank you, but I was speaking of the M-n behavior vs
RET.  It can be easily fixed with a default set to ("now"
current_file_timestamp) where "now" is the string "now", but I will now
stop posting about this.


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