emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: Ignacio Casso <ignaciocasso@hotmail.com>,
	emacs-orgmode@gnu.org, tom@tomdavey.com,
	Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions (was: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)])
Date: Wed, 23 Mar 2022 08:10:05 +1100	[thread overview]
Message-ID: <87pmmdsm2f.fsf@gmail.com> (raw)
In-Reply-To: <87r16umhnj.fsf@localhost>


Ihor Radchenko <yantar92@gmail.com> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> After further reading the source code, I figured that agenda is, in
>> fact, supposed to handle timestamps inside property drawers. Optional
>> arguments for org-at-timestamp-p imply that, in agenda specifically,
>> timestamps inside node properties are considered timestamps despite they
>> are not being parsed as timestamps by org-element.
>
> Even though I fixed the reported issue with agenda not showing headings
> with matching timestamps inside property drawers, this situation is
> revealing a big inconsistency in Org mode's handling of timestamps.
>
> org-at-timestamp-p usage implies that Org syntax for timestamps is not
> only context-dependent, but also depends on current command!
>
> org-at-timestamp-p is called with non-nil argument in a number of
> functions in Org:
> - org-clock-timestamps-change
> - org-mouse-delete-timestamp
> - org-mouse-context-menu
> - org-follow-timestamp-link
> - org-get-repeat
> - org-auto-repeat-maybe
> - org-time-stamp
> - ... many more in org.el
>
> So, depending on the current command, Org may on may not treat objects
> matching org-ts-regexp-both as timestamps.
>
> This situation complicates syntax and makes org-element unreliable when
> dealing with Org buffers.
>
> Should we just simply allow timestamps to be a part of node property
> values? Should we _not_ treat timestamp-looking text outside their
> allowed contexts (like quotes, source blocks, etc) as timestamps?
>

I think we have to be very wary here. I can see any changes here causing
lots of breakage for people. I know for my own use case, I use
timestamps a lot in property draws and various source blocks. I never
want any of them showing up in my agenda.

As an example, I was recently working for a company which required that
you put a timestamp in both a file header and in comments. The format
they used was pretty much the same as an org-mode active timestamp. I
use org mode to tangle the source files I write (as well as manage my
client data, such as todos, invoicing, contacts etc), so these files are
searched for agenda items, but I do not want any of those timestamps
causing lines in my agenda views. These timestamps are most commonly
found in source and example blocks.

I think the only time an org timestamp should be recognised in a source
block is when that source block is an org-mode source block. I don't
think they should ever be 'recognised' in example blocks.  

IN addition, my invoicing solution, which is based on org, uses
timestamps to track invoice periods etc. None of these should ever
appear in the agenda. This information is typically tracked in property
draws.

Unfortunately, I think org timestamps is a bit of a mess and we need to
be very careful about further complicating matters. The inability to
handle timezones is a major limitation IMO. The inability to handle
daylight savings transitions in a consistent manner (particularly for
calculation of periods, duration, etc) is often a source of errors and
if you are unfortunate enough to regularly travel across different
timezones, forget about using org mode to manage your schedule.

I have done several deep dives into org-mode's timestamp stuff, but
usually come back up gasping for air. Managing data and time data is
often far more complicated than it may appear on the surface. I think we
need to be extremely conservative when considering changes in this area
(it is the main reason I've never managed to find a way to add time zone
data - every solution I could think of was either really high on the
level of breakage and frustration it would create for users or it
adversely impacted the convenience/usability of org timestamps). 



  reply	other threads:[~2022-03-22 21:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-12 10:06 [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)] Ignacio Casso
2022-03-12 12:28 ` Ihor Radchenko
2022-03-21 15:58   ` Tom Davey
2022-03-21 23:21     ` Ignacio Casso
2022-03-22  0:50       ` Samuel Wales
2022-03-22 10:02         ` Ihor Radchenko
2022-03-22 10:17         ` Ihor Radchenko
2022-03-22 21:02           ` Tim Cross
2022-03-23 12:07             ` Ihor Radchenko
2022-03-23  0:10           ` Samuel Wales
2022-03-23 12:21             ` Ihor Radchenko
2022-03-24  3:38               ` Samuel Wales
2022-03-22  3:43       ` Tom Davey
2022-03-22  9:47       ` Ihor Radchenko
2022-03-22 10:00         ` Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions (was: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]) Ihor Radchenko
2022-03-22 21:10           ` Tim Cross [this message]
2022-03-22 23:16             ` Tom Davey
2022-03-23  0:25               ` Tim Cross
2022-03-23 13:13             ` Ihor Radchenko
2022-03-22 23:05           ` Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions Nicolas Goaziou
2022-03-23 13:06             ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pmmdsm2f.fsf@gmail.com \
    --to=theophilusx@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=ignaciocasso@hotmail.com \
    --cc=mail@nicolasgoaziou.fr \
    --cc=tom@tomdavey.com \
    --cc=yantar92@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).