|
From: | GNU bug Tracking System |
Subject: | bug#64298: closed (29.0.92; Fixes for several todo-mode bugs) |
Date: | Sun, 02 Jul 2023 09:53:01 +0000 |
Your message dated Sun, 02 Jul 2023 11:52:47 +0200 with message-id <87wmziskr4.fsf@gmx.net> and subject line Re: bug#64298: 29.0.92; Fixes for several todo-mode bugs has caused the debbugs.gnu.org bug report #64298, regarding 29.0.92; Fixes for several todo-mode bugs to be marked as done. (If you believe you have received this mail in error, please contact help-debbugs@gnu.org.) -- 64298: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64298 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems
--- Begin Message ---Subject: 29.0.92; Fixes for several todo-mode bugs Date: Mon, 26 Jun 2023 11:39:35 +0200 User-agent: Gnus/5.13 (Gnus v5.13) This report describes and provides patches for four different bugs in todo-mode.el. Three of the bugs can result in todo-mode file format corruption, and the fourth is a documentation bug, so I think the fixes should all be installed in the release branch, and I'm asking for permission to do that. As with my previous todo-mode bugfix, which also went into the release branch (bug#63811), the patches touch only todo-mode.el and with them all todo-mode unit tests pass. The first bug is further instances of the bug in bug#63811 that made the todo-mode buffer manually editable and hence susceptible to file format corruption. In that bug report I only looked at item editing, but now I've reviewed all cases in todo-mode.el where buffer-read-only is set to nil and found that a number of them could give rise to the same issue. I have fixed these in the same way, by restricting the the scope of nil buffer-read-only. The second bug I encountered while testing one case of the buffer-read-only bugs: currently, when moving a block of done items to another category that does not already have done items, only the first moved done item gets relocated to the target category's done section; the remaining moved done items wrongly end up in the todo section of the following category in the file, and since these items are tagged as done, this breaks the format of non-done todo items. The patch makes sure the moved items are correctly relocated. The third bug I discovered after reading the report of bug#54612, which is about unintendend truncation of sexps resulting from the user globally setting print-length or print-level to a sufficiently small value. The internal file format of todo-mode makes crucial use of specially formatted sexps that are part of the file contents, and if these get truncated, that can break the required format and cause errors when using todo-mode commands. This is prevented by binding print-{length,level} to nil, as in the fix for bug#54612. The fourth bug is a doc bug: the doc string of one todo-mode user option refers to use of a todo-mode insertion command argument that, quite embarrassingly, is a remnant of an earlier state of my revision of todo-mode.el and was actually eliminated before the revision was merged into the Emacs trunk ten years ago. The patch replaces this obsolete doc string with a description of the current behavior (which fortunately is already correctly documented in the Todo mode info manual). Since these four bugs are conceptually independent of each other, I would like to install the fixes in separate commits; is that all right? 2023-06-26 Stephen Berman <stephen.berman@gmx.net> Avoid making todo mode buffers manually editable * todo-mode.el (todo-edit-item--header, todo-set-item-priority) (todo-move-item, todo-item-undone, todo-archive-done-item) (todo-set-category-number): Restrict the scope of nil buffer-read-only to the function calls that change buffer text, thereby preventing todo mode buffers from becoming manually editable and hence possibly corrupted when the minibuffer is in use.txtMhVmq1F63l.txt
Description: Avoid making todo mode buffers manually editable2023-06-26 Stephen Berman <stephen.berman@gmx.net> Ensure correct relocation of moved todo-mode done items * todo-mode.el (todo-move-item): Don't use todo-forward-item when moving done items, to avoid mislocation if done items sections of the the target category was empty before moving. (todo-forward-item): Remove commented out code meant to have the effect of the above change in todo-move-item, but it did not work.txtcNpcpbDHsp.txt
Description: Ensure correct relocation of moved todo-mode done items2023-06-26 Stephen Berman <stephen.berman@gmx.net> Prevent truncation of todo-mode categories sexp * todo-mode.el (todo-delete-file, todo-move-category) (todo-convert-legacy-files, todo-update-categories-sexp) (todo-check-format): Bind print-length and print-level to nil before using prin1 and related functions, to avoid truncating the todo categories sexp and possibly corrupting the file format.txtXcnACjzLv8.txt
Description: Prevent truncation of todo-mode categories sexp2023-06-26 Stephen Berman <stephen.berman@gmx.net> Rewrite obsolete todo-mode.el doc string * todo-mode.el (todo-always-add-time-string): Replace doc string, which was mistakenly retained in the initial merge of this version of todo-mode.el, by a correct description of this user option.txtDBC8a4RPD3.txt
Description: Rewrite obsolete todo-mode.el doc stringIn GNU Emacs 29.0.92 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.6) of 2023-06-23 built on strobelfssd Repository revision: e962cf4ba726943b0f4ea57e1d740742e7618e3a Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12101008 System Description: Linux From Scratch r11.3-100-systemd Configured using: 'configure -C --with-xwidgets 'CFLAGS=-Og -g3' PKG_CONFIG_PATH=/opt/qt5/lib/pkgconfig' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB
--- End Message ---
--- Begin Message ---Subject: Re: bug#64298: 29.0.92; Fixes for several todo-mode bugs Date: Sun, 02 Jul 2023 11:52:47 +0200 User-agent: Gnus/5.13 (Gnus v5.13) On Tue, 27 Jun 2023 17:58:23 +0200 Stephen Berman <stephen.berman@gmx.net> wrote: > On Tue, 27 Jun 2023 15:54:08 +0300 Eli Zaretskii <eliz@gnu.org> wrote: > >>> From: Stephen Berman <stephen.berman@gmx.net> >>> Cc: 64298@debbugs.gnu.org >>> Date: Tue, 27 Jun 2023 14:50:21 +0200 >>> >>> On Tue, 27 Jun 2023 14:37:33 +0300 Eli Zaretskii <eliz@gnu.org> wrote: >>> >>> > I'd like to release Emacs 29.1 _soon_. The only way to ensure this is >>> > not to install on emacs-29 anything that doesn't _have_ to be there. >>> > So please look at this from my vantage point, and try to play "devil's >>> > advocate" against yourself. Then tell me what you think. >>> >>> I understand and appreciate your concerns. So I'll push the revised >>> buffer-read-only fix, the print-{length,level} fix and the two doc fixes >>> to emacs-29, and install the other two patches in master (after the >>> emacs-29 fixes have been merged to master). >> >> Thanks. > > I've now pushed the emacs-29 commits as ee41f07be52, 6ae83322d4c and > 11cead0d73c (unfortunately, I forgot to add the bug # to the first two > commits). I'll keep this bug open until I've installed the two fixes > for master. I've now pushed to the two remaining fixes to master as commit a2ccab18ca2 and am closing this bug. Steve Berman
--- End Message ---
[Prev in Thread] | Current Thread | [Next in Thread] |