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.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32105 in the body.
You can then email your comments to 32105 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32105
; Package
emacs
.
(Mon, 09 Jul 2018 15:55:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Boruch Baum <boruch_baum <at> gmx.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 09 Jul 2018 15:55:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The behavior of function `calendar-read-date' is inconsistent in that
its default is provide the current year, but not the current month or
day of the month.
Patch attached.
In GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2018-05-07, modified by Debian built on binet
System Description: Devuan GNU/Linux 2.0.0 (ascii)
Configured using:
'configure --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.2/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --build x86_64-linux-gnu
--prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.2/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --with-x=yes --with-x-toolkit=gtk3
--with-toolkit-scroll-bars 'CFLAGS=-g -O2
-fdebug-prefix-map=/build/emacs25-NE1ko4/emacs25-25.2+1=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall'
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
[calendar-read-date.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32105
; Package
emacs
.
(Mon, 24 Jun 2019 15:25:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 32105 <at> debbugs.gnu.org (full text, mbox):
Boruch Baum <boruch_baum <at> gmx.com> writes:
> The behavior of function `calendar-read-date' is inconsistent in that
> its default is provide the current year, but not the current month or
> day of the month.
I agree; if we get a default year, then everything should get defaults.
However: The Emacs standard for prompting these days is to put the
default into `M-n', isn't it? The current `calendar-read-date'
requires you to delete the default "2019" if you want another year...
So perhaps that should also be changed, and today's date for all three
questions should be in `M-n'?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32105
; Package
emacs
.
(Mon, 24 Jun 2019 16:54:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 32105 <at> debbugs.gnu.org (full text, mbox):
On 2019-06-24 17:24, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum <at> gmx.com> writes:
>
> > The behavior of function `calendar-read-date' is inconsistent in that
> > its default is provide the current year, but not the current month or
> > day of the month.
>
> I agree; if we get a default year, then everything should get defaults.
>
> However: The Emacs standard for prompting these days is to put the
> default into `M-n', isn't it? The current `calendar-read-date'
> requires you to delete the default "2019" if you want another year...
Yes, that's an inconvenience.
> So perhaps that should also be changed, and today's date for all three
> questions should be in `M-n'?
Agreed.
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?
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.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32105
; Package
emacs
.
(Mon, 24 Jun 2019 20:43:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 32105 <at> debbugs.gnu.org (full text, mbox):
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.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32105
; Package
emacs
.
(Tue, 25 Jun 2019 01:24:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 32105 <at> debbugs.gnu.org (full text, mbox):
On 2019-06-24 22:42, Lars Ingebrigtsen wrote:
> Hm... well, calendar-read seems nice, since it validates the numbers...
OK
> 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.
Reasonable.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32105
; Package
emacs
.
(Mon, 20 Jan 2020 19:51:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 32105 <at> debbugs.gnu.org (full text, mbox):
Boruch Baum <boruch_baum <at> gmx.com> writes:
> On 2019-06-24 22:42, Lars Ingebrigtsen wrote:
>> Hm... well, calendar-read seems nice, since it validates the numbers...
>
> OK
>
>> 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.
>
> Reasonable.
Just to follow up on this, since it was 7 months ago. Did you find
the time to finish up this patch according to the comments by Lars?
It sounds like a good addition to me.
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32105
; Package
emacs
.
(Tue, 21 Jan 2020 04:20:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 32105 <at> debbugs.gnu.org (full text, mbox):
On 2020-01-20 20:50, Stefan Kangas wrote:
> Boruch Baum <boruch_baum <at> gmx.com> writes:
> > On 2019-06-24 22:42, Lars Ingebrigtsen wrote:
> >> 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.
> >
> > Reasonable.
>
> Just to follow up on this, since it was 7 months ago. Did you find
> the time to finish up this patch according to the comments by Lars?
> It sounds like a good addition to me.
I guess this is an example of how mis-communication retards progress. I
expressed approval with Lars' suggestion, but never said that I would be
the one to code it. Do you want to?
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32105
; Package
emacs
.
(Tue, 21 Jan 2020 05:12:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 32105 <at> debbugs.gnu.org (full text, mbox):
tags 32105 - patch
thanks
Boruch Baum <boruch_baum <at> gmx.com> writes:
> I guess this is an example of how mis-communication retards progress. I
> expressed approval with Lars' suggestion, but never said that I would be
> the one to code it. Do you want to?
As I said, I'm just following up on the status. I assumed you would
be interested in doing it since you submitted the patch and expressed
approval for the improvement ideas. Of course, if you will not be
working on it, that is also useful information.
In any case, I'm removing the patch tag, since it seems like more work
is needed here.[1]
Best regards,
Stefan Kangas
Footnotes:
[1] https://debbugs.gnu.org/Developer.html#tags says: "If there's a
patch, but it doesn't resolve the bug adequately or causes some
other problems, this tag should not be used."
Removed tag(s) patch.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Tue, 21 Jan 2020 05:12:02 GMT)
Full text and
rfc822 format available.
Changed bug title to '25.2; calendar-read-date should default to today' from '25.2; calendar-read-date should default to today [PATCH INCLUDED]'
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org
.
(Tue, 21 Jan 2020 10:24:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
You have taken responsibility.
(Thu, 21 Jan 2021 05:43:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Boruch Baum <boruch_baum <at> gmx.com>
:
bug acknowledged by developer.
(Thu, 21 Jan 2021 05:43:02 GMT)
Full text and
rfc822 format available.
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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 18 Feb 2021 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 39 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.