On Sun, Mar 25, 2012 at 1:40 PM, Nicolas Goaziou <n.goaz...@gmail.com> wrote: >> If so, I think it's ultimately a bad idea and it should be rewritten >> using ragel. > > It may be. But it allows for flexibility. Org's syntax is evolving, and > I consider org-element.el as a parser, but also as a guidance in that > process. Since there is no formal description for Org syntax yet, an > org-element.el is more useful than a full-blown parser generator for > now.
Using a parser generator can be flexible too. Big changes in the syntax usually implies big changes in the parsing code. With a tool like ragel the operation is much less painful since the code is generated. Also, if the org syntax can be written as a grammar, it can be safely imported in other software that have a parser for it making the format more portable. > I don't know ragel (save for a short excursion in its website), but I'm > pretty sure that even if it generates elisp code without dependency, any > evolution to Org syntax will require to use it again. At that time, it > may be difficult to find someone able and willing to undertake that > updating task in a reasonable delay (since we're talking about a core > feature). On the other hand, there are quite a few elisp hackers in > Emacs's world. Frankly, I don't know ragel very much either. I've only used it on very simple things. But it's easy to use. You can even execute action at any state while parsing a token (look closely at the example on the homepage). > Now, if ragel can improve org-element.el while preserving its I'm not sure it's possible :/ > flexibility (and a compatible output, since I assume you won't also > rewrite the generic export engine), I'm all ears. Yes, the output of the parser has to remain the same otherwise I would have to rewrite everything :p
