Steven Allen <[email protected]> writes: >>> If the desire is to support parsing org-mode text outside of org-mode, >>> it probably makes sense to replace all instances of "\\S-" in regular >>> expressions with something more generic (e.g., "[ \t\r\n]+"). However, >>> that's a very large search and replace. >> >> Actually, more than that. All the rx-based regexps that make use >> of `space' construct should also be considered. And we cannot just go >> with \s because Org syntax explicitly allow arbitrary whitespace >> (including e.g. zero-width space that we recommend as escape character) >> in many scenarios. I think that the right solution will be wrapping all >> the parser-related staff into org-with-syntax-table. > > There are a lot of entrypoints. Are you thinking about defining some > kind of `org-defun'? Or restricting the entrypoints to a few org-element > functions?
I am thinking about 1. Making sure that org-element parser function all explicitly define the expected syntax table 2. Getting rid of parts of the Org code that do not use the parser and instead rely on ad-hoc regexp parsing. This is a giant effort, but I am hoping to move towards full switch to Org element parser over time. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
