Re: Formal description of Org files

[Marcelo de Moraes Serpa <celoserpa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

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 <
olivier.schwander@chadok.info> wrote:

> Le 15 Apr 2011 14:31, Nick Dokos a écrit:
> > Eric Schulte <schulte.eric@gmail.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 2794 bytes --]