From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 SHcWEeu1WGP+SAAAbAwnHQ (envelope-from ) for ; Wed, 26 Oct 2022 06:22:03 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id AG9JEOu1WGMcowAAG6o9tA (envelope-from ) for ; Wed, 26 Oct 2022 06:22:03 +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 AE07C2CE1D for ; Wed, 26 Oct 2022 06:22:02 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1onXuQ-0005yU-GU; Wed, 26 Oct 2022 00:20:54 -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 1onXuO-0005pO-9b for emacs-orgmode@gnu.org; Wed, 26 Oct 2022 00:20:52 -0400 Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1onXuM-0002kK-8a for emacs-orgmode@gnu.org; Wed, 26 Oct 2022 00:20:51 -0400 Received: by mail-lf1-x129.google.com with SMTP id j16so6689919lfe.12 for ; Tue, 25 Oct 2022 21:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IObmkz8Zie+k0MsROkJSFJw6O2OT70qcYIiaphVrnoc=; b=GNO3Zx41FWR1BvwL7AHMSCfYKZLleGexDxrhe4tI8uUw0ngSTI2H2Hl4egT7Dg+Vlu YoVcouZfX25KTQNLV/YRuxJnDNVkMw5U5hrClXF5BeXRetPgZWtYoQ1/kWoCb6JjqCMj TsPcX0453zJFDlGOf2oyv9HVnJCf88la8G6weA2CfV+rg9Z7aV+eq63zQOYzV6xZKHWw AedK3P3I/4j9PqNigwyB0n5/HvRUIUnAly/47XsUmmWyHcKsm45Dgf24MKvCo9IDHpUd z/bjus7sRnTrlNkvyseacyUr+0tbNx3Sxw7GMW4cTxSLSg1HhQpSgL91bjljOComaN5g 9h5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IObmkz8Zie+k0MsROkJSFJw6O2OT70qcYIiaphVrnoc=; b=zbdGUULRY/5hbm9wotOaiub9xRzV/xPIinnFHJ/ucr8bg1JFfkREUV2PYoSEJpRvIX xDrXKajvoeOeMk8I/Y/KVI0/lNexxze5h1BjJ3dn8c9vtRZx+gu/NSY0RO2kaMsziZwh 7qUJ/oFzTmJ5i4edeXgu+3kVRIPblw7e/WhDTyUMP6rBUV9FC1KWqRBSu92voYYIbM1L duCGA52QuQgDNfGfdSsOl4Y59ACcOsTDCCVHWm6//EwpEOcpyp2xj6ctQtGom+vqLPwZ YzLdyZTFM7KPunO70JjBUqE7RIfONF5ZtZZ5TzZsAa8kEfX50sIsiG7dLxart3g8YrlF TcWA== X-Gm-Message-State: ACrzQf3UGmrSvS4GvvtmVG7Ffm4pOOXxS9hggwO6Okf7TsVlYmAvzBLq itQiLIBeIqW88RFit9XPmeMCfidQ6gFDZWRYLMc= X-Google-Smtp-Source: AMsMyM4Ot7vU33qYPIy25obVsv08U0aFoZZLEKMiB8k6NfnJIjFVJ4x+oOsLEi/2Gz7n6LEgI9p5IzjzbIJQP1FHjLQ= X-Received: by 2002:a05:6512:3a4:b0:4a4:6db7:2d6b with SMTP id v4-20020a05651203a400b004a46db72d6bmr14394187lfp.403.1666758047513; Tue, 25 Oct 2022 21:20:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9a:4d08:0:b0:228:e569:9740 with HTTP; Tue, 25 Oct 2022 21:20:46 -0700 (PDT) In-Reply-To: <87r0yvql3k.fsf@localhost> References: <87zgdms2lq.fsf@mat.ucm.es> <87k04ppp1t.fsf@localhost> <861qqwk778.fsf@gmail.com> <87r0yvql3k.fsf@localhost> From: Samuel Wales Date: Tue, 25 Oct 2022 21:20:46 -0700 Message-ID: Subject: Re: [BUG] Undocumented convention for org-time-stamp-custom-formats to be "<...>" (was: time-stamp in DONE tag is not really displayed) To: Ihor Radchenko Cc: Tim Cross , emacs-orgmode@gnu.org Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::129; envelope-from=samologist@gmail.com; helo=mail-lf1-x129.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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=1666758122; 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=IObmkz8Zie+k0MsROkJSFJw6O2OT70qcYIiaphVrnoc=; b=lA5eIya+SP25zvUnAzeZbFiINQRjtDShHv/Q8VM48kC9EF0exK8sTmQNPGJ2hxSlFw5cok v1npL2P/zdwpE25HJu9jnSr7KhX0tzkGm7tFWXX/THyOHVG+KxYVF3P9kRqQDsh4luTEQl JcLA4ExddCVPujOvB2/A4wTBS374MbgnpFhJqHaoJyFdZzRYKKEv0lpt7onp9YH79EPlVN xaY/CM8lhCHv7exg7xeRuiVZ/7NpQOtc8ijeuQXLAWcWGQKFjghD/hGA0SBYUJL72HRNSN nbQjhGCX4gxTYNjHg69OL4AWrW5/RSXWZasV04JPAS5uSfgfiJah0YDQpwCvJQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1666758122; a=rsa-sha256; cv=none; b=ZxrK3RAxn/JHEhmZNwYZ2Kgw4suKjocnW5zD9bbVZHF3ppgZNqYANr8C2NUQqOect7F14h A6IHDl2CNYIgzmSFpO4rvJHqBftCg2P1o2NIqFscpy8dSGILScdnv2dywseQLnT0CghFw1 50IjG4R8z63wdZsPX1FvOKaD1dZxvLqEq6yhQziuajLPwE/vbvk8xvj5u/ZFavE9MfcJkP XIVSnvEalE3qKKRFJP8Pn0NVz1H/4E0OS5qYU63mXuwaKQT/Gs3v2iK+dW24sO5g8i6yLn WxxX5TvZgmcu8WJGFhUNZreuzWdGx9nj6mfUCn6HPI4hikfx8jRheLyyKWExxg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GNO3Zx41; dmarc=pass (policy=none) header.from=gmail.com; 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: -7.71 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=GNO3Zx41; dmarc=pass (policy=none) header.from=gmail.com; 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: AE07C2CE1D X-Spam-Score: -7.71 X-Migadu-Scanner: scn0.migadu.com X-TUID: 11ecrYfKLlfF please feel free to ignore this post if it is off topic. i cannot tell if it is of topic or not. long ago i wanted to mke it so that if i hovered over a timesamp it woud produce a time span notation relative to . and also i wanted to make a custom time stamp format for the same purpose. but i think was not possible. if any changes are actually done to custom format, perhaps, if not already done, hooks can be strategically added or so. On 10/25/22, Ihor Radchenko wrote: > 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 > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com