Re: More clocktable breakage

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Achim Gratz <Stromeko@nexgo.de> writes:

> and org-at-block-p only matches in the first line of a dynamic block,

[...]

> 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.

This old and buggy function has nothing to do with the problem at hand.
Also, even if it used org-at-dblock-start-re, it would still be buggy
(is it closed? is it in an example block?).

> Anyway, when you changed the scope of that function you'd need to check
> all users of the API and fix them where necessary.

Really? I thought it would magically happen... somehow. Silly me.

> 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.

The main user of that predicate is the agenda, now.

> It's also obvious that the test coverage of this is bad.

Patch welcome.

> 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).

Another idea is to add an optional argument to `org-at-timestamp-p' to
allow "sloppy" matching (or strict matching, it doesn't really matter)
and skip checks when it is required. So all functions requiring this
predicate can make use of it, as long as they call it properly.

WDYT?

> 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.

I don't think there is a bug there. Do you have an ECM?

Regards,