Re: More clocktable breakage

[Achim Gratz <Stromeko@nexgo.de>]

Nicolas Goaziou writes:
> 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?

That's what I've been asking the whole time: when you changed that
predicate, you've basically cut off some of its consumers.  It looks
like bad factoring to me to then splitting the same predicate based on
some argument.  I'd rather pull out the old sloppy matching into a new
predicate for instance.

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

I don't use planning, so no.  But it seems to me that the only way for
org-element-context to deliver a 'timestamp is when pos is on a planning
line (that may be wrong, I just don't see where else a 'timestamp would
be returned).  In that case we've already left the cond, so testing for it
doesn't do anything useful.  I'm also not really sure why the existing
exceptions from the "true" timestamp (planning, property and clock-log)
are any different than "dynamic block" would be (with the appropriate
change of the doc string of course).y


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves