Re: Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions

[Ihor Radchenko <yantar92@gmail.com>]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Ihor Radchenko <yantar92@gmail.com> writes:
>
>> 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.
>
> This is orthogonal to syntax. I think the docstring of that predicate is
> clear: `org-at-timestamp-p' is a convenience function for broader uses
> of timestamps, which existed before Element.

Let me clarify. What I have in mind is my proposal about using
org-element for fontification:
https://orgmode.org/list/87ee7c9quk.fsf@localhost

The usage org `org-at-timestamp-p' in multiple places in org.el implies
that Org treats timestamp-like strings as actual timestamps even when
org-element does not recognise them. Then, if, say, I implement a new
fontification system purely relying on org-element, some timestamp-like
strings will remain interactive (for example, using mouse context menu)
but will not be fontified.

Any other idea relying on org-element might also suffer from such
issues.

>> 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?
>
> Allowing Org syntax in property values is creating another set of
> problems: often the value is really a string that Org shouldn't try to
> interpret.

Is there an easy example demonstrating the potential problem?
For reference, I did try to implement parsing node-property values and
even did not fail any tests, except the one directly checking the
current timestamp-in-property-drawer parsing.

Best,
Ihor