Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Ihor Radchenko <yanta...@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
