GNU bug report logs - #32105
25.2; calendar-read-date should default to today

Previous Next

Package: emacs;

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Emacs Bug Reporting <bug-gnu-emacs <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, "Edward M. Reingold" <reingold <at> cs.uiuc.edu>
Subject: 25.2; calendar-read-date should default to today [PATCH INCLUDED]
Date: Mon, 9 Jul 2018 11:53:44 -0400
[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):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 32105 <at> debbugs.gnu.org,
 "Edward M. Reingold" <reingold <at> cs.uiuc.edu>
Subject: Re: bug#32105: 25.2;
 calendar-read-date should default to today [PATCH INCLUDED]
Date: Mon, 24 Jun 2019 17:24:30 +0200
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):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 32105 <at> debbugs.gnu.org,
 "Edward M. Reingold" <reingold <at> cs.uiuc.edu>
Subject: Re: bug#32105: 25.2; calendar-read-date should default to today
 [PATCH INCLUDED]
Date: Mon, 24 Jun 2019 12:52:57 -0400
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):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 32105 <at> debbugs.gnu.org,
 "Edward M. Reingold" <reingold <at> cs.uiuc.edu>
Subject: Re: bug#32105: 25.2;
 calendar-read-date should default to today [PATCH INCLUDED]
Date: Mon, 24 Jun 2019 22:42:31 +0200
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):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 32105 <at> debbugs.gnu.org,
 "Edward M. Reingold" <reingold <at> cs.uiuc.edu>
Subject: Re: bug#32105: 25.2; calendar-read-date should default to today
 [PATCH INCLUDED]
Date: Mon, 24 Jun 2019 21:22:53 -0400
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):

From: Stefan Kangas <stefan <at> marxist.se>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: Glenn Morris <rgm <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 "Edward M. Reingold" <reingold <at> cs.uiuc.edu>, 32105 <at> debbugs.gnu.org
Subject: Re: bug#32105: 25.2; calendar-read-date should default to today
 [PATCH INCLUDED]
Date: Mon, 20 Jan 2020 20:50:22 +0100
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):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: Glenn Morris <rgm <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 "Edward M. Reingold" <reingold <at> cs.uiuc.edu>, 32105 <at> debbugs.gnu.org
Subject: Re: bug#32105: 25.2; calendar-read-date should default to today
 [PATCH INCLUDED]
Date: Mon, 20 Jan 2020 23:19:40 -0500
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):

From: Stefan Kangas <stefan <at> marxist.se>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: Glenn Morris <rgm <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 "Edward M. Reingold" <reingold <at> cs.uiuc.edu>, 32105 <at> debbugs.gnu.org
Subject: Re: bug#32105: 25.2; calendar-read-date should default to today
 [PATCH INCLUDED]
Date: Tue, 21 Jan 2020 06:11:28 +0100
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):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 32105-done <at> debbugs.gnu.org,
 "Edward M. Reingold" <reingold <at> cs.uiuc.edu>, Boruch Baum <boruch_baum <at> gmx.com>
Subject: Re: bug#32105: 25.2; calendar-read-date should default to today
 [PATCH INCLUDED]
Date: Thu, 21 Jan 2021 00:41:57 -0500
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.