Hi, I'm currently toying with the idea of trying a tree-sitter parser for Org. The very static nature of a shared object parser (knowing TODO keywords are pretty dynamic for example) is a challenge I'm not sure to overcome ; to be honest even without that I can't say I'll manage to do it.
Having a tree-sitter parser would be really great in my opinion, at least it's a clearer way to "freeze" the syntax with some tests describing the syntax tree with S-expressions. And tree-sitter seems to be the popular sought after solution to slowness in parsing (and incremental parsing of org files would help with big files in my opinion) On Tue, Sep 15, 2020, at 09:58, Przemysław Kamiński wrote: > Hello, > > I oftentimes find myself needing to parse org files with some external > tools (to generate reports for customers or sum up clock times for given > month, etc). Looking through the list > > https://orgmode.org/worg/org-tools/ > > and having tested some of these, I must say they are lacking. The > Haskell ones seem to be done best, but then the compile overhead of > Haskell and difficulty in embedding this into other languages is a drawback. > > I think it might benefit the community when such an official parser > would exist (and maybe could be hooked into org mode directly). > > I was thinking picking some scheme like chicken or guile, which could be > later easily embedded into C or whatever. Then use that parser in org > mode itself. This way some important part of org mode would be outside > of the small world of elisp. > > This is just an idea, what do you think? :) > > Best, > Przemek > > Gerry Agbobada