GNU bug report logs -
#55284
28.1; TODO Mode - Unable to operate if `calendar-date-style' is set to 'iso
Previous Next
To reply to this bug, email your comments to 55284 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55284
; Package
emacs
.
(Fri, 06 May 2022 03:29:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Christos Ballas <cballas99 <at> me.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 06 May 2022 03:29:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Starting from emacs -q
(setq calendar-date-style 'iso)
M-x todo-show -> Test -> Test
In the newly constructed buffer type "i i Test2<enter>"
Emacs will now hang until you type "C-g"
In GNU Emacs 28.1 (build 52, x86_64-w64-mingw32)
of 2022-04-04 built on AVALON
Repository revision: 5a223c7f2ef4c31abbd46367b6ea83cd19d30aa7
Repository branch: heads/emacs-28.1
Windowing system distributor 'Microsoft Corp.', version 10.0.19043
System Description: Microsoft Windows 10 Home (v10.0.2009.19043.1645)
Configured using:
'configure --without-dbus --with-native-compilation
--without-compress-install CFLAGS=-O2'
Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB
(NATIVE_COMP present but libgccjit not available)
Important settings:
value of $LANG: ENG
locale-coding-system: cp1252
Major mode: Todo
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
buffer-read-only: t
line-number-mode: t
visual-line-mode: t
indent-tabs-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
cl-print time-stamp cl-extra seq byte-opt gv bytecomp byte-compile cconv
time-date subr-x thingatpt help-fns radix-tree help-mode todo-mode
cl-loaddefs cl-lib diary-lib diary-loaddefs cal-menu calendar
cal-loaddefs iso-transl tooltip eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
make-network-process native-compile emacs)
Memory information:
((conses 16 76843 9177)
(symbols 48 7960 1)
(strings 32 27028 1585)
(string-bytes 1 869841)
(vectors 16 16123)
(vector-slots 8 256973 11816)
(floats 8 32 236)
(intervals 56 477 0)
(buffers 992 14))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55284
; Package
emacs
.
(Fri, 06 May 2022 06:45:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 55284 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 6 May 2022 00:01:37 +0100
> From: Christos Ballas via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> Starting from emacs -q
> (setq calendar-date-style 'iso)
> M-x todo-show -> Test -> Test
> In the newly constructed buffer type "i i Test2<enter>"
> Emacs will now hang until you type "C-g"
It looks like todo-mode.el is basically incompatible with any
calendar-date-style but 'american'.
(Btw, you aren't supposed to set calendar-date-style directly. But
going through the Customize interface, as you are supposed to, doesn't
help in this case, because the relevant todo-mode patterns are
defconst's.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55284
; Package
emacs
.
(Fri, 06 May 2022 09:00:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 55284 <at> debbugs.gnu.org (full text, mbox):
On Fri, 06 May 2022 09:44:27 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 6 May 2022 00:01:37 +0100
>> From: Christos Ballas via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> Starting from emacs -q
>> (setq calendar-date-style 'iso)
>> M-x todo-show -> Test -> Test
You left out the prompt for a Todo item; typing an item and RET at the
prompt will insert the item into the category with the date header in
ISO format. However, the date is not correctly fontified, which is a
sign of trouble...
>> In the newly constructed buffer type "i i Test2<enter>"
>> Emacs will now hang until you type "C-g"
>
> It looks like todo-mode.el is basically incompatible with any
> calendar-date-style but 'american'.
It also works with the 'european' style, but indeed not with 'iso'.
> (Btw, you aren't supposed to set calendar-date-style directly. But
> going through the Customize interface, as you are supposed to, doesn't
> help in this case, because the relevant todo-mode patterns are
> defconst's.)
Yes, this is something that's always bothered me (as Todo mode
maintainer) but IIRC my brief investigation of the issue way back when
convinced me that it was not easy (for me) to fix. I don't use the ISO
date style in Todo mode myself and saw no complaints till now, so I
haven't tried again to fix it. Unfortunately, I can't afford to do
time-consuming debugging and testing now, so if it is possible to fix
this bug, I would encourage someone better acquainted than me with the
Calendar/Diary handling of dates to do it. Otherwise, I'll look into it
when I have the time.
One of the issues I remember being bothered by is if someone wants to
change back and forth between date styles. It seems that this is not
(fully) supported by diary-lib.el (I'm filing a separate bug report
about that). If that can be fixed, it might be applicable to Todo mode.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55284
; Package
emacs
.
(Sun, 05 Nov 2023 22:02:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 55284 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
merge 55284 66395
thanks
On Sat, 07 Oct 2023 23:27:46 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> On Sat, 7 Oct 2023 19:06:55 +0000 "Nathan R. DeGruchy" <nathan <at> degruchy.org> wrote:
>
>> I am trying to explore using 'todo-mode' as a todo list and while I can
>> see and create entries in todo-mode using the normal functions, trying
>> to edit an item seems to cause emacs to soft-lock. I can reproduce this
>> in a config-less emacs via `emacs -Q`.
>>
>> Basically, I have a todo-file at $HOME/.config/emacs/todo/tasks.todo,
>> this was created when using `todo-show` initially. The contents are not
>> very complex:
>>
>> (("Emacs" . [1 0 0 0]) ("Home" . [1 0 0 0]))
>> --==-- Emacs
>> [2023-10-07] Learn Todo Mode
>>
>> ==--== DONE
>> --==-- Home
>> [2023-10-07] Get new wiper blades
>>
>> ==--== DONE
>>
>> When on either of the items, if I hit 'e' to edit them, it causes emacs
>> to lock up, specifically around `todo-done-item-p()`. I found this out
>> by enabling `toggle-debug-on-quit`, reproducing the error, and the
>> C-g'ing out of the loop/lockup. I also tried to trace through the
>> todo-edit-item with edebug-defun. Stepping through, it seems to reach
>> the same predicate function and ... stop.
>>
>> I'm not sure where to go from here.
>
> On Sat, 07 Oct 2023 14:37:00 -0500 LdBeth <andpuke <at> foxmail.com> wrote:
>
>> As we have discussed on IRC, the nonstandard timestamp format is the cause.
>
> Yes. This is a duplicate of bug#55284. At the time that bug was
> reported, I didn't have time to try fixing it (being the todo-mode
> maintainer), and later, unfortunately, I forgot about it. I'll try to
> look into it soon, but, as I noted in that bug thread, I think it's not
> easy to fix. One issue is that todo-mode basically employs the same
> handling of date formats as diary-lib.el, and the ISO date style causes
> problems there too, see bug#55286.
I've finally attended to this bug. The problem is due to using a faulty
regular expression for matching todo date headers in the ISO format.
There was a related bug report years ago about a diary display problem
with the ISO format (bug#8583), and the fix for that (whose author
conceded it was "ugly") points the way to a fix for todo-mode, see the
attached patch (which I have to concede is even uglier and more
complicated than the fix for bug#8583, but I couldn't find a better
way). (I actually had been aware of the diary bug and the fix, but
didn't try to apply it to todo-mode back then; I don't remember exactly
why but I guess because I concluded it was not straightforward to adapt
the fix to todo-mode and since I didn't use the ISO format myself I
lacked motivation, also because there had been no todo-mode bug reports
about it -- until bug#55286 (and now the current bug), but by then I had
forgotten about bug#8583.)
>> The hang is cause by the while loop `todo-item-start' not properly handle fail
>> case, however.
>>
>> This patch would at least fix the hang.
>>
>> ---
>> LdBeth
>>
>> --- todo-mode.el.old 2023-10-07 14:28:59.000000000 -0500
>> +++ todo-mode.el 2023-10-07 14:30:20.000000000 -0500
>> @@ -5242,8 +5242,8 @@
>> ;; Buffer is widened.
>> (looking-at (regexp-quote todo-category-beg)))
>> (goto-char (line-beginning-position))
>> - (while (not (looking-at todo-item-start))
>> - (forward-line -1))
>> + (while (and (not (looking-at todo-item-start))
>> + (= (forward-line -1) 0)))
>> (point)))
>>
>> (defun todo-item-end ()
>
> Thanks. Even though this doesn't eliminate other problems with using
> the ISO date style in todo-mode (or in the Emacs Diary), since it does
> prevent the infinite loop here, it may be a good stopgap.
With the attached patch I think this stopgap should be unnecessary: the
while-loop should no longer fail when the ISO date format is used
(barring any bugs in the patch, and if there are, it should fail so they
can be found and fixed).
However, using the ISO date format in todo-mode does necessitate
additional changes, in the code for editing todo item headers, which the
attached patch also includes.
Although with this patch todo-mode now supports the ISO date format,
there remains a problem. Todo mode (like the Emacs Diary) uses the date
format specified by calendar-date-display-form, which is a user option
that has three default styles (American, European and ISO), which you
can change by customizing `calendar-date-style' or by executing
`calendar-set-date-style'. But if you change it, that breaks using
todo-mode with any existing todo file that was created using a different
date format, in the same way that trying to use the ISO format with
todo-mode fails without the attached patch (i.e., the current bug). (As
noted above with reference to bug#55286, the diary is subject to similar
breakage.)
After I came up with the attached patch to support the ISO date format
in todo-mode, I started tackling the issue of changing the date format,
and I now have what I think is a viable solution. However, to implement
it I've had to make extensive changes in the todo-mode code, and also to
part of the internal structure of todo files (but not to the UI), and
I'm still testing these changes. They include essentially the changes
in the attached patch (though partly in a more general form).
Therefore, what I'd like to do first is install this patch, after
waiting several days for any feedback. I'll open a new bug to post and
discuss the more extensive changes I'd like to make.
Steve Berman
[Message part 2 (text/x-patch, attachment)]
Merged 55284 66395.
Request was from
Stephen Berman <stephen.berman <at> gmx.net>
to
control <at> debbugs.gnu.org
.
(Sun, 05 Nov 2023 22:02:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#55284
; Package
emacs
.
(Sun, 12 Nov 2023 14:12:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 55284 <at> debbugs.gnu.org (full text, mbox):
On Sun, 05 Nov 2023 23:00:36 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> merge 55284 66395
> thanks
>
> On Sat, 07 Oct 2023 23:27:46 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
>> On Sat, 7 Oct 2023 19:06:55 +0000 "Nathan R. DeGruchy" <nathan <at> degruchy.org> wrote:
>>
>>> I am trying to explore using 'todo-mode' as a todo list and while I can
>>> see and create entries in todo-mode using the normal functions, trying
>>> to edit an item seems to cause emacs to soft-lock. I can reproduce this
>>> in a config-less emacs via `emacs -Q`.
>>>
>>> Basically, I have a todo-file at $HOME/.config/emacs/todo/tasks.todo,
>>> this was created when using `todo-show` initially. The contents are not
>>> very complex:
>>>
>>> (("Emacs" . [1 0 0 0]) ("Home" . [1 0 0 0]))
>>> --==-- Emacs
>>> [2023-10-07] Learn Todo Mode
>>>
>>> ==--== DONE
>>> --==-- Home
>>> [2023-10-07] Get new wiper blades
>>>
>>> ==--== DONE
>>>
>>> When on either of the items, if I hit 'e' to edit them, it causes emacs
>>> to lock up, specifically around `todo-done-item-p()`. I found this out
>>> by enabling `toggle-debug-on-quit`, reproducing the error, and the
>>> C-g'ing out of the loop/lockup. I also tried to trace through the
>>> todo-edit-item with edebug-defun. Stepping through, it seems to reach
>>> the same predicate function and ... stop.
>>>
[...]
> I've finally attended to this bug. The problem is due to using a faulty
> regular expression for matching todo date headers in the ISO format.
[...]
> However, using the ISO date format in todo-mode does necessitate
> additional changes, in the code for editing todo item headers, which the
> attached patch also includes.
[...]
> Therefore, what I'd like to do first is install this patch, after
> waiting several days for any feedback.
I've now pushed the patch to master as commit 0bfe764fe56.
Steve Berman
This bug report was last modified 1 year and 276 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.