From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Roland Winkler" Newsgroups: gmane.emacs.bugs Subject: bug#10323: 24.0.92; docstring diary-date-forms Date: Tue, 8 Jun 2021 17:44:37 -0500 Message-ID: <62165.9663.313205.24767@gargle.gargle.HOWL> References: <87mxapsbhd.fsf@niu.edu> <87a6o87mmq.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19161"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 10323@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 09 00:45:17 2021 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 1lqkTE-0004ps-8E for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 09 Jun 2021 00:45:16 +0200 Original-Received: from localhost ([::1]:53748 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqkTC-00083S-NO for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 08 Jun 2021 18:45:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48826) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqkT1-00083G-5G for bug-gnu-emacs@gnu.org; Tue, 08 Jun 2021 18:45:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48443) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lqkT0-0002gs-UR for bug-gnu-emacs@gnu.org; Tue, 08 Jun 2021 18:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lqkT0-0002ut-AP for bug-gnu-emacs@gnu.org; Tue, 08 Jun 2021 18:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Roland Winkler" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Jun 2021 22:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10323 X-GNU-PR-Package: emacs Original-Received: via spool by 10323-submit@debbugs.gnu.org id=B10323.162319228711178 (code B ref 10323); Tue, 08 Jun 2021 22:45:02 +0000 Original-Received: (at 10323) by debbugs.gnu.org; 8 Jun 2021 22:44:47 +0000 Original-Received: from localhost ([127.0.0.1]:59989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lqkSl-0002uE-IE for submit@debbugs.gnu.org; Tue, 08 Jun 2021 18:44:47 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lqkSh-0002tz-Cx for 10323@debbugs.gnu.org; Tue, 08 Jun 2021 18:44:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50474) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lqkSc-0002Up-1H; Tue, 08 Jun 2021 18:44:38 -0400 Original-Received: from [2600:1700:5650:f790::12] (port=37832 helo=regnitz) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lqkSb-0001k9-SD; Tue, 08 Jun 2021 18:44:37 -0400 In-Reply-To: <87a6o87mmq.fsf@gnus.org> 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" Xref: news.gmane.io gmane.emacs.bugs:208267 Archived-At: On Wed Jun 2 2021 Lars Ingebrigtsen wrote: > > The patterns on the list must be MUTUALLY EXCLUSIVE and should not match > > any portion of the diary entry itself, just the date component. > > Here the first character following the date itself is considered part of > > the date. > > (I'm going through old bug reports that unfortunately got no response at > the time.) > > This was nine years ago, but the doc string is still the same here. > And... I'm not quite sure I understand either the current doc string or > the proposed enhancement, really. :-) > > > Actually, this is not completely true either, and it becomes relevant if > > one wants to indent the diary entries for which the `backup' mechanism > > of diary-european-date-forms applies. If one has the diary entries > > > > 18/12/2011$ foo bar > > 18/12/2011 foo baz > > 18 December foo bar > > > > the first two entries are indented as one might expect it; yet > > the third one is not indented (i.e., with `backup' all > > whitespace characters following immediately the date become part > > of the date) > > Perhaps something from this discussion of the problem should be > added to the doc string? If so, please do go ahead and modify it. It took me a while to refresh my memories about this bug report. The problem is about how diary-date-forms arranges the splitting of a diary entry into a date (specifying when to display the diary entry) and the associated text (that will be displayed for this date). The current code assumes, indeed, that there is a separator in between these two components of an entry. This separator is given by the last element of each date form in diary-date-forms and the separator is swallowed by the "fancy diary display" machinery for diary entries. This behavior is undocumented which makes it hard to figure out how the predefined elements of diary-date-forms actually work, and this was, I believe, my original motivation for the bug report almost ten years ago. For most predefined date forms, the separator is a single character. For example, given an entry "08/06/2021foo bar", the letter f is treated as separator that is swallowed so that the fancy diary buffer displays the entry as "oo bar". Probably, this undocumented behavior is rarely causing problems for users because it is more common that the first character following the date is a space. Yet worse, the "backup" approach used for the third date form in diary-european-date-forms implies that any non-word characters at the beginning of the text are not displayed in the fancy diary buffer. For example, the diary entry "08 June @John: hello" is displayed as "John: hello" instead of "@John: hello". This may confuse not only elisp coders but also ordinary users of the emacs diary. A cleaner solution was probably that the last element of each date form defined the beginning of the text that will be displayed for this date. However, the current code has existed for many years so that likely users have arranged themselves with its oddities and a better solution must keep this in mind, too. (I haven't figured out why, according to the docstring of diary-date-forms, the patterns defined by different date forms must be mutually exclusive. I'd find it more natural if just the first matching pattern wins.) What do others think about this?