Links not recognized about tree-sitter-org HOT 5 CLOSED

That's intended, objects are parsed outside of tree-sitter to allow customization and simplify the parser

from tree-sitter-org.

Ok, thank you for the information!

from tree-sitter-org.

@milisims out of curiosity, what are other objects that could in theory be parsed by treesitter but are handled as expr besides a link? Looking at #4, it just appears that links are a quite basic element in org that need to be parsed anyway (or else they defeat their purpose)

from tree-sitter-org.

what are other objects that could in theory be parsed by treesitter but are handled as expr besides a link?

All of them, really. However, adding them into the parser locks in where they must appear and the form/markers that they use. So I think it's more useful to have a system that can use queries to generate objects rather than hard-coding them in the parser. This allows for customization (which I use personally, I like my backticks for code!), and won't cause conflicts if someone wants to do something unforeseen and creative with the org syntax that wouldn't be allowed by default. The system is set up now to allow maximal customization, enforcing syntax only on the basic org elements. I'm working on a back-end for nvim/lua that has an expressive element and object API for exactly this kind of thing. My original goal was to have a public version by March, but work got in the way :S

On the other hand, if someone really wants to use tree-sitter to parse the objects, they could in principle just write an object-parser as a tree-sitter grammar, and inject it in the appropriate locations. This approach is also far less complex than adding the objects into this grammar. I tried adding them in this grammar for a while, and it's... finicky. Mostly because they cause conflicts that are difficult to resolve.

As for specific objects to add here? I have a branch locally that re-adds listitem checkboxes, but I'm having difficulty resolving a few tests. So that will be added at some point. I'm specifically against adding objects that are within text (markup, latex entities, statistic cookies, links, etc). Anything that has a specifically defined location is more likely to be directly implemented, like this latex environment & checkboxes. While list descriptions might fit this idea theoretically, I don't want them to be added. If they are, then this:

- +[ ] desc :: item+

Is parsed as something like (listitem (description (expr) (expr) (expr)) (paragraph (expr)), and we would need to define a query that allows for any type of markup we wanted to use across that specific boundary. Instead, if we allow just the checkbox, it just gets parsed as a paragraph and we can apply the same markup rules to get a item with strikeout.

from tree-sitter-org.

I think I understand the problem better now, thanks for the explanation 👍

from tree-sitter-org.