* bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED]
@ 2018-07-09 15:53 Boruch Baum
2019-06-24 15:24 ` Lars Ingebrigtsen
0 siblings, 1 reply; 9+ messages in thread
From: Boruch Baum @ 2018-07-09 15:53 UTC (permalink / raw)
To: 32105; +Cc: Edward M. Reingold
[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]
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
[-- Attachment #2: calendar-read-date.patch --]
[-- Type: text/x-diff, Size: 1598 bytes --]
--- a.el 2018-07-09 11:50:31.882699070 -0400
+++ b.el 2018-07-09 11:51:07.636744090 -0400
@@ -2243,18 +2243,19 @@
If optional NODAY is t, does not ask for day, but just returns
\(month 1 year); if NODAY is any other non-nil value the value returned is
\(month year)"
- (let* ((year (calendar-read
+ (let* ((today (calendar-current-date))
+ (year (calendar-read
"Year (>0): "
(lambda (x) (> x 0))
- (number-to-string (calendar-extract-year
- (calendar-current-date)))))
+ (number-to-string (calendar-extract-year today))))
(month-array calendar-month-name-array)
(completion-ignore-case t)
(month (cdr (assoc-string
(completing-read
"Month name: "
(mapcar 'list (append month-array nil))
- nil t)
+ nil t nil nil
+ (aref month-array (1- (calendar-extract-month today))))
(calendar-make-alist month-array 1) t)))
(last (calendar-last-day-of-month month year)))
(if noday
@@ -2263,7 +2264,8 @@
(list month year))
(list month
(calendar-read (format "Day (1-%d): " last)
- (lambda (x) (and (< 0 x) (<= x last))))
+ (lambda (x) (and (< 0 x) (<= x last)))
+ (number-to-string (calendar-extract-day today)))
year))))
(defun calendar-interval (mon1 yr1 mon2 yr2)
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED]
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
0 siblings, 1 reply; 9+ messages in thread
From: Lars Ingebrigtsen @ 2019-06-24 15:24 UTC (permalink / raw)
To: Boruch Baum; +Cc: 32105, Edward M. Reingold
Boruch Baum <boruch_baum@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED]
2019-06-24 15:24 ` Lars Ingebrigtsen
@ 2019-06-24 16:52 ` Boruch Baum
2019-06-24 20:42 ` Lars Ingebrigtsen
0 siblings, 1 reply; 9+ messages in thread
From: Boruch Baum @ 2019-06-24 16:52 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 32105, Edward M. Reingold
On 2019-06-24 17:24, Lars Ingebrigtsen wrote:
> Boruch Baum <boruch_baum@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED]
2019-06-24 16:52 ` Boruch Baum
@ 2019-06-24 20:42 ` Lars Ingebrigtsen
2019-06-25 1:22 ` Boruch Baum
2021-01-21 5:41 ` Stefan Monnier
0 siblings, 2 replies; 9+ messages in thread
From: Lars Ingebrigtsen @ 2019-06-24 20:42 UTC (permalink / raw)
To: Boruch Baum; +Cc: 32105, Edward M. Reingold
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED]
2019-06-24 20:42 ` Lars Ingebrigtsen
@ 2019-06-25 1:22 ` Boruch Baum
2020-01-20 19:50 ` Stefan Kangas
2021-01-21 5:41 ` Stefan Monnier
1 sibling, 1 reply; 9+ messages in thread
From: Boruch Baum @ 2019-06-25 1:22 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 32105, Edward M. Reingold
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED]
2019-06-25 1:22 ` Boruch Baum
@ 2020-01-20 19:50 ` Stefan Kangas
2020-01-21 4:19 ` Boruch Baum
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Kangas @ 2020-01-20 19:50 UTC (permalink / raw)
To: Boruch Baum; +Cc: Lars Ingebrigtsen, Edward M. Reingold, 32105
Boruch Baum <boruch_baum@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED]
2020-01-20 19:50 ` Stefan Kangas
@ 2020-01-21 4:19 ` Boruch Baum
2020-01-21 5:11 ` Stefan Kangas
0 siblings, 1 reply; 9+ messages in thread
From: Boruch Baum @ 2020-01-21 4:19 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Lars Ingebrigtsen, Edward M. Reingold, 32105
On 2020-01-20 20:50, Stefan Kangas wrote:
> Boruch Baum <boruch_baum@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED]
2020-01-21 4:19 ` Boruch Baum
@ 2020-01-21 5:11 ` Stefan Kangas
0 siblings, 0 replies; 9+ messages in thread
From: Stefan Kangas @ 2020-01-21 5:11 UTC (permalink / raw)
To: Boruch Baum; +Cc: Lars Ingebrigtsen, Edward M. Reingold, 32105
tags 32105 - patch
thanks
Boruch Baum <boruch_baum@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."
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED]
2019-06-24 20:42 ` Lars Ingebrigtsen
2019-06-25 1:22 ` Boruch Baum
@ 2021-01-21 5:41 ` Stefan Monnier
1 sibling, 0 replies; 9+ messages in thread
From: Stefan Monnier @ 2021-01-21 5:41 UTC (permalink / raw)
To: Lars Ingebrigtsen
Cc: Glenn Morris, 32105-done, Edward M. Reingold, Boruch Baum
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@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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-01-21 5:41 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).