[ragel-users] GSoC 2012 -- Elisp backend for Ragel

Aurélien Aptel aurelien.aptel at gmail.com
Tue Mar 27 20:03:09 UTC 2012

On Sun, Mar 25, 2012 at 1:40 PM, Nicolas Goaziou <n.goaziou at 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

> 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

ragel-users mailing list
ragel-users at complang.org

More information about the ragel-users mailing list