GNU bug report logs -
#32105
25.2; calendar-read-date should default to today
Previous Next
Reported by: Boruch Baum <boruch_baum <at> gmx.com>
Date: Mon, 9 Jul 2018 15:55:02 UTC
Severity: wishlist
Found in version 25.2
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
Full log
Message #35 received at 32105-done <at> debbugs.gnu.org (full text, mbox):
I just pushed a patch which makes `calendar-read-date` default to today
for both the month and day of month, and it makes it use the `M-n`
instead of a non--empty minibuffer for the year as well.
Stefan
Lars Ingebrigtsen [2019-06-24 22:42:31] wrote:
> Boruch Baum <boruch_baum <at> gmx.com> writes:
>
>> The function is inconsistent in that it uses function `calendar-read'
>> for the year and day values, but `completing-read' for the month value.
>> Should `calendar-read' behave like `completing-read'? Maybe it should
>> have additional optional arguments for everything required by
>> `completing-read', and then just call `completing-read'? Or just not use
>> `calendar-read' at all, and deprecate it?
>
> Hm... well, calendar-read seems nice, since it validates the numbers...
>
>> If you `completing-read' -type behavior for entry of the year field, how
>> many history entries are you going to give the user? You could use
>> `history-length', like so:
>>
>> (let* ((n-year (calendar-extract-year (calendar-current-date)))
>> (a-year (- n-year (/ history-length 2)))
>> (z-year (+ n-year (/ history-length 2))))
>> (number-sequence a-year z-year))
>>
>> This has a disadvantage that for certain use-cases future years might
>> not make sense.
>
> I think just putting the current year in M-n is fine -- we don't have to
> mess with the history at all.
>
> That is, something conceptually like:
>
> (read-from-minibuffer "Year: " nil nil t nil "2019")
>
> Then 2019 is in M-n and can be edited, and just hitting RET will also
> return 2019.
This bug report was last modified 4 years and 126 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.