Comments (5)
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.
Related Issues (20)
- Latex errors out HOT 1
- Hyperlink after headline causes error HOT 1
- Add tree-sitter-org to nvim-treesitter's list of supported languages? HOT 1
- Activity/Discussion on HackerNews posting HOT 1
- Support for markup: `*bold*`, `/italic/`, `_underlined_`, `=verbatim=`, `~code~` and `+strike-through+` HOT 1
- Hyphen in table cell and empty lines between parent/child line items causes error HOT 2
- LaTeX support HOT 3
- Fixed width areas elements HOT 1
- Empty check boxes are treated as 3 separate expression unlike all other checkboxes HOT 9
- error when expr appears at end of dynamic_block
- Sexp diary entries support HOT 7
- Publish to crates.io HOT 5
- Not compiling via Neovim HOT 4
- Fix issue with latest tree-sitter HOT 1
- Plan not parsed when line starts with tab HOT 4
- Build fails with no such file or directory, uv_cwd
- Paragraph starting with LateX inline math causes parsing to fail
- Incomplete date range causes Error HOT 3
- Unexpected switch to drawer content
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tree-sitter-org.