Re: More clocktable breakage

[Achim Gratz <Stromeko@nexgo.de>]

Nicolas Goaziou writes:
> Sadly, what a "timestamp" is depends on what function is asking. AFAICT,
> there are three categories of "timestamps".

Well, taking a further setp back, before Org started to have a formal
syntax anything that looked like a timestamp was treated as one.  The
different categories of timestamps really arise from the fact that we
now have syntactical timestamps and non-syntactical ones.  This in turn
requires that each function dealing with timestamps needs to specify
what exactly it wants to deal with, but as this discussion amply shows,
that isn't quite as straightforward as one would think.

> Let's consider the following examples:
>
>   (1)
>   SCHEDULED: <2017-04-30 dim.>
>
>   (2)
>   CLOCK: [2017-04-30 dim. 08:10]--[2017-04-30 dim. 08:11] =>  0:01
>
>   (3)
>   : <2017-04-30 dim.>
>
>   (4)
>   :PROPERTIES:
>   :DATE: <2017-04-30 dim.>
>   :END:
>
>   (5)
>   # <2017-04-30 dim.>
>
>   (6)
>
>   #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>"
>
> The first category is the "strict" one, which follows Org syntax
> definition. None of the examples above belong to that category.
> `org-element-context' should be the relative predicate, which means that
> it probably shouldn't return a timestamp object on planning lines, as it
> does at the moment.

I'd say anything org-element-* should exclusively return syntactical
things.  Context dependence needs to be dealt with elsewhere.

> The second category, which is a super-set of the previous one, is
> "agenda" one. Historically, Org allowed to insert timestamps in property
> drawers, e.g., as in (4), and use them in the agenda. So basically, this
> category contains "every timestamp that would appear as a plain
> timestamp in the agenda if it were active". `org-at-timestamp-p' is
> currently the relative predicate for that category. Note that the
> category also contains (2) if inactive timestamps are meant to be
> displayed in the agenda.

I would call that meta-syntax or maybe quoted syntax: you are looking at
a proper timestamp, to be used somewhere else where a timestamp is
needed, but in a context that doesn't specify a timestamp itself.  There
are many analogous cases elsewhere in Org, so it may be a fruitful
endeavour to consider this in a more general fashion.  Providing
timestamps as arguments to any processing functions (built into Org or
otherwise) carries the requirement that they should syntactically be
correct as a timestamp (so they can be converted into a timestamp object
at the place of use), so all functions to insert and edit a timestamp
need to work at those places.

> The last category, a super-set of the "agenda" one, is the "convenience"
> category. Basically, it contains every occurrence of what looks like
> a timestamp, but isn't necessarily one. Obviously, every example given
> above fits in there, as in every case, you can ignore that Org has
> a context-dependant grammar and pretend you are on a timestamp. There is
> no predicate relative to that category, but `org-at-timestamp-p'
> docstring suggests to use (org-in-regexp org-ts-regexp).

If I'd follow that road, I could edit what looks like a timestamp
everywhere, regardless of context.  I don't know if that's the right
thing to do and I don't even expect consensus among the Org user base.
I personally see no need to do that.

> So, about the predicates, I guess we could move the second one into
> "org-agenda.el" and rename it `org-agenda-at-timestamp-p'. However,
> using `org-at-timestamp-p' for the last category seems a bit
> far-stretched to me, since it doesn't always match timestamps. In
> particular, (3) and (5) sound counter-intuitive to me and I wouldn't
> like it from a developer standpoint. `org-at-timestamp' is also not
> really needed for the first category, since there is already
> `org-element-context'.

Agreed.  That's why I'm hesitant to change the org-at-timestamp-p to
(org-in-regexp org-ts-regexp) in the edit functions.  What I don't agree
with (if I've read you correctly) is the implied assertion that the
clocktable example is in the last category.  Or maybe it is at the
moment, but it ought to be in the second one.  I consider only examples
(3) and (5) to be in the "last" category.

> Yet, `org-at-timestamp-p' is something users are going to look after.
> Different names may also introduce confusion (remember `org-at-regexp-p'
> and `org-in-regexp-p'?). So, even if it looks like bad factoring to you,
> a single predicate, or even two if we set "agenda" apart, with
> a docstring explaining the different categories and how to select them
> may also be a good natural choice. Hence my suggestion.

Since org-at-timestamp-p already has an argument, adding a second one
doesn't look appealing to me, especially when the first one would often
be nil.  Maybe it's possible to change the definition of that argument
(which would need the equivalence between t meaning 'inactive).

> WDYT? Do you have any other concrete proposal?

I really only need the clocktables to work again, which they'd be if
they were in the second category, I gather.  I've monkeypatched
org-at-timestamp-p with an ((org-at-block-p)) clause so I'm good for
now, but per our discussion this wouldn't be an acceptable solution.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada