[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLU
From: |
Lars Ingebrigtsen |
Subject: |
bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED] |
Date: |
Mon, 24 Jun 2019 22:42:31 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Boruch Baum <boruch_baum@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.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no