From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id 6LEEORvZe2YDSAAAqHPOHw:P1 (envelope-from ) for ; Wed, 26 Jun 2024 09:02:20 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 6LEEORvZe2YDSAAAqHPOHw (envelope-from ) for ; Wed, 26 Jun 2024 11:02:20 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=dKUdiJYI; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1719392539; 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=nqgtxHpXO8LtvvB/mpvWc55komNSbEBtaK2FsmzFSP0=; b=iOpuyvpkGQgG3zeJRwQrQd4Dqlfm1rLPuH0pTrPxeCYPBcPIFOpaCPLPynAkkFfMwGFjr3 KqnBgrBMLI/YTYEOgp7FC8jXsG61uuoKqpLN8xzWVuqOadpWMWEwoo5TVBfmyBYEvOPhBc CTycStUbgi99g089J+P+LjLNi1mxShfKhMgXzI+9bq+UuOqywB8HUTn50zHcx7xLHgM1sb CCIN29pxODxvNpaL8uhy23BLWPOIbac21FYfxqJrOtYYjrO+UOXMvQspe6slIaHBCwYwjS OnOr+bK1IE1mEVX2eEj4u3ViqGGs2KvUfOEIvohvXyCHVUHRu5Iu1VxD5wPkeQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1719392539; a=rsa-sha256; cv=none; b=a04FLMX2HlMyEEkXRVLIvhEWkj+/9FvxTO9L+Q2bxw8li9F61/VfeWnHNs8ZQeAVIbQ222 +tZc3AJO7cEK+qWilo/S7ek+mOCuqamttRARO1hNrCrUahZYIN7iXHbz6+C7F2STcSb1Yh SIosyi0xuUzkvrbxJQz3sbx4mRFv6TeTp0+yA8BZskJD5qzSONxAigcNSnlWhPtZmtdfTL H2BogmAfEoBWuQ3bWWxNtRktSLJnVAl3vjtY3KNgEyX8lOVBhCSsfJsJ3nBXhItIDopLoq z8ji9csDVQW2YZA+GEeKAFaPgcrQ4t0xCaokCga4v5JI+LH9F//s/ZzGxMGIEw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=dKUdiJYI; 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" 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 4345C3906F for ; Wed, 26 Jun 2024 11:02:18 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sMOWs-00047o-8M; Wed, 26 Jun 2024 05:01:26 -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 1sMOWo-00047N-Vf for emacs-orgmode@gnu.org; Wed, 26 Jun 2024 05:01:22 -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 1sMOWg-0004wz-KQ for emacs-orgmode@gnu.org; Wed, 26 Jun 2024 05:01:22 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 4E7E5240104 for ; Wed, 26 Jun 2024 11:01:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719392470; bh=UbZyf+Q00J72ayt3+7BE+ITNxK+7JjHz+rDZem5WQag=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=dKUdiJYIZmplczVPR2XKATtI2HPFDD1L3GlboQdiGy6Ro3BB6+HpUzBVZGa3mTq/1 zwXs/4r/2tRGYsN1HI+T0QwCCtVI3m4AlIT+Az0cYEhXqmwbstPUJPIjy89AKJj1Gw wRXVz7mvyJKgJS0msvncGAJWSAqK37tiptf7zdCxX7nJOzrLQcCM+28Z21LB0wj8Ml r1WHfiN0Y1fMo5xsRJP66G9d+MtBGSpc5229uXcUWeqwdSrBrWcjQkfa+7+EqB3iFn hR0PTE1XL/+AyTHClqE1FGQv8yijmkmtlDeb2FufiIecjAdwLJDxer9VA90vr7YmGi gmSYJSn8FRzJw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W8Fzn3YMBz9rxB; Wed, 26 Jun 2024 11:01:09 +0200 (CEST) From: Ihor Radchenko To: Morgan Smith Cc: emacs-orgmode@gnu.org, Sanel Zukan Subject: Re: Parse malformed clocklines (was: Re: [PATCH] lisp/org-clock.el (org-clock-sum): Rewrite regex using rx) In-Reply-To: References: <87r0f9b9n2.fsf@localhost> <87frvpyzrf.fsf@localhost> <875xu6aee8.fsf@localhost> <87bk3x9bpv.fsf@localhost> <87h6do7zj6.fsf@localhost> Date: Wed, 26 Jun 2024 09:02:35 +0000 Message-ID: <87ikxw3wlw.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: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.59 X-Spam-Score: -6.59 X-Migadu-Queue-Id: 4345C3906F X-Migadu-Scanner: mx11.migadu.com X-TUID: qNNOnPnY9tMN Morgan Smith writes: >> I think that the best course of action when a problematic timestamp >> without opening/closing time is encountered is: >> >> 1. Warn user >> 2. Still calculate the duration, assuming 0s in time (simply because >> previous versions of Org mode did it) >> >> (2) is kind of debatable, but I can imagine some users might make use of >> >> such feature by putting clocks by hand: >> CLOCK: [2023-11-15 Wed]--[2023-11-16 Thu] => 24:00 >> >> These users may then simply suppress the warning. > > I'm very tempted to just make it hard rule that clocklines need to be > fully specified. If you take a look at the attached patch, it shows one > way we could do this. > > First, I modify the timestamp parser so the ":*-end" variables don't > always inherit the ":*-start" variables. They can be nil independent of > the start. > - (setq year-end (or (nth 5 date) year-start) > - month-end (or (nth 4 date) month-start) > - day-end (or (nth 3 date) day-start) > - hour-end (or (nth 2 date) (car time-range) hour-start) > - minute-end (or (nth 1 date) (cdr time-range) minute-start)))) > + (setq year-end (or (nth 5 date) (and time-range year-start)) > + month-end (or (nth 4 date) (and time-range month-start)) > + day-end (or (nth 3 date) (and time-range day-start)) > + hour-end (or (nth 2 date) (car time-range)) > + minute-end (or (nth 1 date) (cdr time-range))))) This is harmless, but also does nothing - if there is no year, month, and date specified, `date-end' would never match. > 1. Will changing the timestamp parser have far-reaching implications? > Is this something I should avoid? Clock lines and timestamps are not only used to calculate clock sums. They can, for example, be exported. Or they can be used manually, by reading them as text. So, any kind of change in the parser should be considered extremely carefully. > Then in the clockline parser I ensure that every single field is set. > If it isn't, then I set the timestamp to nil so it won't be used. > 2. Is there a way to give user errors in the parser code? I'm using > `org-element--cache-warn' in my patch but I'm not sure that's the right > thing to do. (if it is the right thing then we need to define it > earlier in the file) This is not acceptable. org-element is a _parser_. It has nothing to do with interpretation of timestamps. Moreover, there is no notion of "invalid" syntax in Org mode - any text is a valid Org syntax, although it may be interpreted as plain text if it does not fit any existing markup. I still insist that it is a job of the Elisp code that interprets the clock lines (the clock sum function) to display warnings and otherwise analyze the timestamp components. We may also hint potential problems in org-lint. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at