emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Formal description of Org files


From: Marcelo de Moraes Serpa
Subject: Re: [O] Formal description of Org files
Date: Fri, 15 Jul 2011 13:07:25 -0500

Hi guys,

I was going to create a new thread, but this one seems to fit exactly what I'm looking for.

I'm creating a web app that interacts with orgmode files and allows you to edit orgmode files on the browser. The edit part is not done. I'm quite good at _javascript_, and I wouldn't mind hacking something akin to orgmode elisp code and this will be what I'll do if everything else fails, but wouldn't using a grammar be a cleaner and more elegant solution?

Thanks,

Marcelo.

On Wed, Apr 20, 2011 at 7:37 AM, Olivier Schwander <address@hidden> wrote:
Le 15 Apr 2011 14:31, Nick Dokos a écrit:
> Eric Schulte <address@hidden> wrote:
>
> > If one goal of such a formal description of Org-mode would be to parse
> > text Org-mode files into an abstract syntax tree ...
> >
>
> I think this should be the starting point: what are the goals for all this?
> Providing a formal description in EBNF is one thing. Preparing an attribute
> grammar for input into a specific tool is another (and probably an order of
> magnitude - or two - harder) - what would the resulting parser(s) be used for?
>
> Clear(er) answers to these questions should go a long way towards figuring out
> what specific tool(s) should be used - or whether it's at all necessary to
> worry about that.

The primary goal I see for such a formal description is to provide a
specification that third party parsers are supposed to respect. Writing
a real parser may be too much project specific and difficult to
generalize in a way usable by the community.

During the development of neo[1], I was confronted to the need of
defining what is an org file (actually, what is an headline, a todo
keyword, a tag, a drawer, a timestamp, etc) and determining what is the
expected output of a parser.

Maybe the most appropriate format for such a description would be free
text, letting parser developers choosing between context-free grammars,
regexps or whatever they want ( with a bunch of example org files for
reference and tests).

Regards,

Olivier

[1] I am just discovering this thread



reply via email to

[Prev in Thread] Current Thread [Next in Thread]