From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id kNcPJDW0WGPxCwEAbAwnHQ (envelope-from ) for ; Wed, 26 Oct 2022 06:14:45 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id IKvUIzW0WGO2KQEAauVa8A (envelope-from ) for ; Wed, 26 Oct 2022 06:14:45 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 41A422CA56 for ; Wed, 26 Oct 2022 06:14:44 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1onXly-0004JP-Jf; Wed, 26 Oct 2022 00:12:10 -0400 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 1onXlu-00049z-Pd for emacs-orgmode@gnu.org; Wed, 26 Oct 2022 00:12:06 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1onXll-0001gg-16 for emacs-orgmode@gnu.org; Wed, 26 Oct 2022 00:12:06 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 84E98240101 for ; Wed, 26 Oct 2022 06:11:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1666757513; bh=X8JEbRoWNJvMRFh0D1YTNBdsBQrbP45rl18enbM5f0Q=; h=From:To:Cc:Subject:Date:From; b=LT2ux/YTpCOBlK4qw5nueXYiTR8JNmkIVsp1Q3trpPFG+7+VT1t7Vk3c5rNcf0SUQ YMLPwbGc4fDcKiXTgA6lYoBB6gp3UGuNRvTRENdH0Uut14SDM/2kSXfBgesMTKuVtY wZiaCqyu+MKM5hWqPwW3ZN013K7JVymMssEzIUufOfKEH1ceN6vrhg39hvW2yWgbsW 8dEY9QqBCV/8XRmDofr7EJmz3umh85CZ9RYlufy1XYJ37qWwnXC8X0qA/oiAeWcxz6 PMD2tiQIFzPiaakdxTLPuF8HQM8Dpy1AG9LiWQN7LrtQd502+oaYkT4qBOx5KN3/+R iKnpCMu2crFjA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MxwP41MDzz9rxB; Wed, 26 Oct 2022 06:11:51 +0200 (CEST) From: Ihor Radchenko To: Tim Cross Cc: emacs-orgmode@gnu.org Subject: Re: [BUG] Undocumented convention for org-time-stamp-custom-formats to be "<...>" (was: time-stamp in DONE tag is not really displayed) In-Reply-To: <861qqwk778.fsf@gmail.com> References: <87zgdms2lq.fsf@mat.ucm.es> <87k04ppp1t.fsf@localhost> <861qqwk778.fsf@gmail.com> Date: Wed, 26 Oct 2022 04:12:31 +0000 Message-ID: <87r0yvql3k.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Emacs-orgmode" Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1666757684; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=PveEWHF3v1uopQtHP4gz6n62Ze8tcH5THGFZnPvT4K0=; b=q0V1GameaaVweaTJS9AshGObtN+dos86h6GocNuSLiqD5XBIpHx2YrEZ7UVGq0LaSh/EbS AVWffiPCzPrMYF0WcvxcOKazHDlXMCsJTDJo6LhVquXH1vVhbumNJBsBnQyAWfYcVXnPls y2HzS0QfJg6mS1speXys9Hg+YO9LgYPjuWVMtcGrkAadzu2rvswCgiFOeU6kLZVDHPnHCE loFqhw088GcffbMrJVnqtsVufy5g2NtXbQVLQd45FXCh5P36bToY7LfE1X4CLIXOCQt9fH LlaIW5AXcGVcib29OSJFOqjvWoVedNh0BzuTiYQFXe24Z3lImK3Nh7FD5RVrgA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1666757684; a=rsa-sha256; cv=none; b=sUi9nFDc4Ux+DwI6upMF62uPRcOD7ciJJ3qhcrf+sqZr5W4wOX14sTrdhU68/dCqRlq5hZ PGZKtiZ3NZ5nTq5QMYAgXdPyIouIWgN5bdoNNgyK5xp0CiU3UwlcUEh+UTbVuHRenLOk9W NDDhRPpdDW7fGK9u8wQo0EOhETS6Mm89bLU8+4+14WtNU56RIQ2/k66gX5m/SH66qsc0W2 XLhSXwj0eB51J2hBFiGReYsQeSAGWh77MppitP6dS9IAVDV1/7QeuIceBztN5Yy0G2tDeF jc7kMSHD3RVggTcABXWJVdyiZtbLGQVK1qRk2EACpYayP1qSvym7paLQ24s+sg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="LT2ux/YT"; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -1.91 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="LT2ux/YT"; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 41A422CA56 X-Spam-Score: -1.91 X-Migadu-Scanner: scn1.migadu.com X-TUID: wYsXvwaAaovl Tim Cross writes: >> I propose to do the following: >> 1. org-time-stamp-formats and org-time-stamp-custom-formats will be >> treated as is, unless they contain "<" and ">" and the first and the >> last char. >> 2. If the formats do contain <...>, strip the "<" and ">". >> 3. Document (2) in the docstrings. >> >> Any objections? > > Little unsure/confused regarding what is being proposed here. > > - If we are removing <...>, does that mean we just retain [..] for > inactive timestamps and all other timestamps are 'active' by default? org-time-stamp-formats is a constant. Users are not supposed to change it. So, the proposed stripping of "<" and ">" has a pure purpose of not breaking third-party code that might be using its current default value. It is more about some internal code assumptions. org-time-stamp-custom-formats currently has the following docstring: Custom formats for time stamps. See format-time-string for the syntax. These are overlaid over the default ISO format if the variable org-display-custom-times is set. Time like %H:%M should be at the end of the second format. The custom formats are also honored by export commands, if custom time display is turned on at the time of export. There is nothing in the docstring indicating that "<" and ">" are required or used in any way. The current Org code assumptions only create confusion among the users. I propose to strip "<" and ">" just to avoid breakage if users happened to set org-time-stamp-custom-formats to the value with "<...>" that is required to make this defcustom working in older Org versions. If users abused the undocumented behavior and used "[...]", we do not need to worry as it is out of what was promised. At the end, old user settings of org-time-stamp-custom-formats should remain working within docstring promises. Old user code using org-time-stamp-formats constant should also remain working. But users will not need to provide brackets in org-time-stamp-custom-formats after the proposed change. The above is the most safe way to retain backwards compatibility while removing the existing confusion with the docstring. > - How will this change impact code which distinguishes active/inactive > timestamps based on presence/absence of <..> and [..]? org-time-stamp-formats value will not change. org-time-stamp-custom-formats value had no impact on buffer text---just the overlayed timestamp display. No code should be affected. > - What impact will this have on existing org files? None. > - Will this cause issues in parsing when you may have dates/times which > are not supposed to be timestamps, but will look the same as > timestamps? How will you distinguish them? No buffer text will be affected. > Personally, I like the clear distinction between what is a timestamp and > what isn't and what is an active timestamp and what is an inactive > timestamp. There is nothing about active/inactive timestamps in the discussed variables. The usage of "<" and ">" is historical and mostly ignored by Org code. First and last characters are simply stripped, and the required brackets are being used when inserting the actual timestamps. The proposed change simply aims to remove the undocumented requirement about brackets. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at