From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#67331: 30.0.50; New Todo mode feature: changing item date style Date: Thu, 23 Nov 2023 10:06:46 +0200 Message-ID: <8334wwhp0p.fsf@gnu.org> References: <87r0kj5dgt.fsf@gmx.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39587"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 67331@debbugs.gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 23 09:08:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r64l6-000A7m-4g for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 Nov 2023 09:08:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r64kh-0001mA-Ew; Thu, 23 Nov 2023 03:07:59 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r64kg-0001li-Cy for bug-gnu-emacs@gnu.org; Thu, 23 Nov 2023 03:07:58 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r64kg-0002Zf-12 for bug-gnu-emacs@gnu.org; Thu, 23 Nov 2023 03:07:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r64kj-0007yc-Mz for bug-gnu-emacs@gnu.org; Thu, 23 Nov 2023 03:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 Nov 2023 08:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67331 X-GNU-PR-Package: emacs Original-Received: via spool by 67331-submit@debbugs.gnu.org id=B67331.170072683230580 (code B ref 67331); Thu, 23 Nov 2023 08:08:01 +0000 Original-Received: (at 67331) by debbugs.gnu.org; 23 Nov 2023 08:07:12 +0000 Original-Received: from localhost ([127.0.0.1]:60539 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r64jv-0007x8-EY for submit@debbugs.gnu.org; Thu, 23 Nov 2023 03:07:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r64js-0007wi-FZ for 67331@debbugs.gnu.org; Thu, 23 Nov 2023 03:07:09 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r64jj-0002Uk-3S; Thu, 23 Nov 2023 03:06:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=0DJ8JLaoUCAQUqqJ1U+TeRnxPKp08aoqqjTJppgxazg=; b=QB5B15PGbMg7 Apd8OZsw5qGHb6KRncMciKEg8kUof51IRquGtfF8OypAJmiCHHcOuS+OQiDYFEthGC4XG56eMvsAZ ZEyLYRcXk942jH8vEbJ0tA9GzkoVVP6p2bJ2aQ/zsnj1uavxz3crX8UPGYHCbD3ZCjbCYYogPiAkL dyHvICeSFAhTp3gD2rW6z47kBCy5n5bkYDpvB0KWMY7fHRF68WCeMA86dPGi2lUleOO0H5iWq7xXQ OT5TcEd6OyYXDnl3O78VmGmu5ZhWY8O0Nl8GLcwSrOsjsWNtOYtidB9pVPGZztzSR2CWnEWsZFDRe +v1mwjxJkas7JdRQ3cuOEA==; In-Reply-To: <87r0kj5dgt.fsf@gmx.net> (message from Stephen Berman on Tue, 21 Nov 2023 16:32:34 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:274797 Archived-At: > From: Stephen Berman > Date: Tue, 21 Nov 2023 16:32:34 +0100 > > This post is a followup to bug#66395, where I posted (and subsequently > installed) a patch to support the ISO date style in Todo mode item > headers. As I pointed out in that bug thread, despite supporting > different date styles, Todo mode does not support interactively and > automatically changing between different date styles. I have attempted > to add this functionality to Todo mode, and the attached patch contains > my work-in-progress implementation. I'm still testing these changes, so > even if they are deemed acceptable I'm not yet ready to install them, > but they raise some questions and how I proceed will be influenced and > perhaps decided by the answers to these questions. > > The rest of this post is directed mainly to the Emacs maintainers and I > apologize to them for its length, but unless they want to leave it > entirely up to me how to proceed with these changes, I think they need > to know in at least some detail what the issues are. Let me take a step or two back, and ask whether Todo mode needs to support different styles, let alone interactive changes between styles? IOW, what bad things will happen if Todo mode supported only one fixed style? I'm asking this because it sounds like adding this support raises quite a few issues whose resolution is hairy at best, and in some cases causes real user-visible problems. Refusing to support more than one style will eliminate all these issues, with little or no effort. If you do have to support the various styles, my next question is: why not make the style a display-only feature? That is, keep using a single style in the TODO files, but reformat the date to a user-specified style at display time. This should at least avoid the complications of incompatible files, switching between file formats, whether and how should all the existing files be converted to the selected style, etc. After all, why should users care about the internal format of how time stamps are recorded on a TODO file, if they use Todo mode to display and edit those files? Failing these solutions that avoid the complications, here are my opinions about the issues you bumped into: > - Although the use and effect of this feature is confined to > todo-mode.el, it depends on a making a change to calendar.el, as you > can see in the above summary and in the patch. The reason, as I > already noted in bug#66395, is that Todo mode date styles are > specified by `calendar-date-display-form', which you can change by > customizing `calendar-date-style' or by executing > `calendar-set-date-style'. To keep this connection I added a hook to > calendar.el callable from the latter function, that can be used to > trigger the date header changes in Todo mode (but it's not a hook in > the usual sense of being intended for user customization; rather, it's > intended for use by packages). There is precedence for this in commit > a8f4bb8361, where I similarly added a hook to diary-lib.el for the > benefit of todo-mode.el. In addition, since the hook has the value > nil by default, there is no change to the default behavior of the > Emacs Calendar (or Diary). So, is this change to calendar.el > acceptable? I think this is acceptable, but we need commentary for this hook to explain the subtleties you mention above. > - My implementation of this feature crucially involves a change in the > internal form of todo files. Till now the first line of each todo > file has contained a sexp listing the categories in the file (this > line is hidden in todo-mode), but to allow switching date styles I > have augmented this sexp to also contain a specification of the > current date style used by the item headers in the file. A number of > existing todo-mode functions make use of this sexp, so they have also > had to be adapted. All these changes are strictly internal, so the > Todo mode UI remains unchanged. The implementation also includes > automatically converting existing todo files to the augmented metadata > format, so that users of Todo mode can continue using existing todo > files, as well as the new functionality, without needing to be aware > of the internal changes. But once converted, the todo files will not > be compatible with previous versions of todo-mode.el. This would be a > problem if someone wanted to use the same todo files on different > systems, not all of which have an Emacs where todo-mode.el has these > changes. > > Is this problem considered unacceptable? It is certainly undesirable. But we already did something similar, for example in the format of desktop files. See commits c96983efef and 20defc5538. > So is it acceptable to change the metadata format and the item header > for each todo file on demand instead of for all todo files at once? I think so, yes. But again, such changes are undesirable in the first place. > - Another thorny issue is how to deal with unit tests. Currently, there > are a number of tests for todo-mode.el using ERT. Since they all > require a todo file as input data and many make use of the file > metadata (currently in the old format), at least these tests will > require adjusting. So should there be parallel tests for todo-mode > with the new and with the previous metadata format? Or should the > older format be declared obsolete? (However, AFAIK there is no formal > obsoletion mechanism for data formats as opposed to functions and > variables.) I think the decision about this is contingent on the > decision about allowing reverting the format for backwards > compatibility. If we keep supporting both formats, even if the old one is deprecated, we will need to keep the tests for that old format. Deprecation is not removal, so removing the tests (which already exist) sounds like not the best idea to me. > Finally, I want to point out an issue that I think is mainly orthogonal > to the new feature and the preceding considerations, but it helps > clarify the extent of the feature. Currently, Todo mode supports item > date headers with either the American, European or ISO date style, but > all items can only be displayed with the same style, and that > restriction will persist if the changes discussed here are installed: > then you can switch date styles, but doing so changes all item headers > in a visited todo file. In other words, there can be no mixing of date > styles within a todo file, or when switching between todo files. This > restriction is justified by avoiding ambiguity if dates are displayed > simultaneously in the European and American styles with numbers for > months. Admittedly, `calendar-date-display-form' uses month names by > default in these styles, which avoids ambiguity (and there's no > ambiguity between the ISO style and the other styles, unless years are > displayed with just the two least significant digits, which is common in > the American and European styles but AFAIK the ISO standard requires > four digits for years). Hence, at least for such display forms, mixing > date display styles should be possible (though whether it's desirable is > questionable). I haven't given serious thought to how to implement > that, nor to how it would interact with the proposed feature of > switching date styles without mixing, but it would likely require > changes to the implementation in the attached patch. I think it's entirely reasonable to support only one style for displaying TODO items. I cannot think about a reason for displaying different items using different styles. Thanks.