From: Lars Ingebrigtsen <larsi@gnus.org>
To: Boruch Baum <boruch_baum@gmx.com>
Cc: 32105@debbugs.gnu.org, "Edward M. Reingold" <reingold@cs.uiuc.edu>
Subject: bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED]
Date: Mon, 24 Jun 2019 22:42:31 +0200 [thread overview]
Message-ID: <m37e9aogug.fsf@gnus.org> (raw)
In-Reply-To: <20190624165257.eyivujzaoxebbl2w@E15-2016.optimum.net> (Boruch Baum's message of "Mon, 24 Jun 2019 12:52:57 -0400")
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
next prev parent reply other threads:[~2019-06-24 20:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-09 15:53 bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED] Boruch Baum
2019-06-24 15:24 ` Lars Ingebrigtsen
2019-06-24 16:52 ` Boruch Baum
2019-06-24 20:42 ` Lars Ingebrigtsen [this message]
2019-06-25 1:22 ` Boruch Baum
2020-01-20 19:50 ` Stefan Kangas
2020-01-21 4:19 ` Boruch Baum
2020-01-21 5:11 ` Stefan Kangas
2021-01-21 5:41 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m37e9aogug.fsf@gnus.org \
--to=larsi@gnus.org \
--cc=32105@debbugs.gnu.org \
--cc=boruch_baum@gmx.com \
--cc=reingold@cs.uiuc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.