emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32105: closed (25.2; calendar-read-date should default to today)


From: GNU bug Tracking System
Subject: bug#32105: closed (25.2; calendar-read-date should default to today)
Date: Thu, 21 Jan 2021 05:43:02 +0000

Your message dated Thu, 21 Jan 2021 00:41:57 -0500
with message-id <jwvh7na3n0u.fsf-monnier+emacs@gnu.org>
and subject line Re: bug#32105: 25.2; calendar-read-date should default to 
today [PATCH INCLUDED]
has caused the debbugs.gnu.org bug report #32105,
regarding 25.2; calendar-read-date should default to today
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
32105: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32105
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 25.2; calendar-read-date should default to today [PATCH INCLUDED] Date: Mon, 9 Jul 2018 11:53:44 -0400 User-agent: NeoMutt/20180512
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: calendar-read-date.patch
Description: Text Data


--- End Message ---
--- Begin Message --- Subject: Re: bug#32105: 25.2; calendar-read-date should default to today [PATCH INCLUDED] Date: Thu, 21 Jan 2021 00:41:57 -0500 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
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.



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]