Re: More clocktable breakage

[Achim Gratz <Stromeko@nexgo.de>]

Nicolas Goaziou writes:
>>>>
>>>>      #+BEGIN: clocktable :tstart "<2006-08-10 Thu 10:00>" :tend "<2006-08-10 Thu 12:00>"
>>>>      #+END: clocktable
>
> These are not timestamps. Even though they look like timestamps, you
> wouldn't want them to appear in the agenda. So `org-at-timestamp-p' is
> correct, IMO. Moreover, its docstring says
[…]

Well, that's the change you made that I pointed at earlier.  The
functionality of org-shift* has unfortunately regressed due to
that change you introduced by "hardening" the recognition of timestamps.
And no, to the user they really are timestamps in the arguments of a
dynamic block, splitting syntactical hairs aside.

> so ISTM a correct fix would be to have the function you're calling (I
> don't remember it) use this instead of `org-at-timestamp-p'.

I already said that the fix might not be the right one, although it
would be in the same spirit as the exceptions already present for
properties drawers, planning lines and clocks and org-at-block-p only
matches in the first line of a dynamic block, so I'd say it's still
sufficiently constrained.

N.B.: The regex used in org-at-block-p is overbroad since it matches the
whole block, I think it should use org-at-dblock-start-re instead.

Anyway, when you changed the scope of that function you'd need to check
all users of the API and fix them where necessary.  The main users of
that predicate were and still are the org-shift* family of commands and
they do expect a looser recognition than what you implemented based on
the docstring.  Maybe that's true in other places also, I haven't
checked.  It's also obvious that the test coverage of this is bad.  So
that looser recognition would need to be factored out again or you
revert this predicate and apply the stricter check where it matters (the
agenda functions, most likely).

Also, again, I think that function is buggy even without these issues as
the only code I can find in org-element-context that deals with
timestamps is conditional on being on a planning line and if that's true
we should never get there.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs