Complying with the *New exporter* framework

[pinard]

Hi, Masafumi.

Granted that the meaning of the word new fades while the time goes on, there is something in Org that's called the New exporter, to solve the problem that each exporter prior to this big overhaul was doing its best effort at digesting and understanding an Org file, with the result that the same Org file was not exported consistently to different backends.

Nicolas Goaziou undertook to write a single Org mode parser in Emacs Lisp that was producing a single, standardized interpretation of an Org file, and to adapt all pre-existing exporters, ripping of their Org file analysis and connecting it to the common parser instead. It has been a lot of work, generated tons of dicsussions, and took quite a while to complete. Since Org 8.0 or 8.1, all that work is essentially done.

My suggestion while opening this issue, which admittedly, is not a small one, is to revise org-js so it sticks to the common understanding of the new exporter framework as much or as far as possible. While some may say that the Emacs Lisp parser is the reference, there has been a good attempt at documenting its features. I do not know if the syntax draft has been updated while some tiny later changes were discussed or adopted, but it should not be far from the actual truth anyway.

If you look at the page http://orgmode.org/worg/dev/, you'll find a section titled Reference documentation containing a small number of pointers to other documents, which could be perused to estimate the amount or extent of changes needed in org-js for aiming compliance.

François

[wallyqs]

@pinard (Commenting since something similar would be needed for org-ruby)I think what it would help in this case is for Org mode to have a documented set of examples of the features that can be exported, along with its output. Even though, Org syntax and exporters can be referenced from worg, I believe there is not a set of examples or specs that other exporters can reference to base their implementation upon, so I think there is missing work there. I tried doing some of that here: https://github.com/wallyqs/org-mode-features but output is a bit old now.

Links:

• http://orgmode.org/worg/dev/org-export-reference.html
• http://orgmode.org/worg/dev/org-syntax.html

[pinard]

A difficulty for automation: there is no prescription about how to generate HTML. Each HTML exporter is free to do its own way, so one cannot compare an HTML output with another. The parsing is at stake here, not the generation, so automation would need some standard way to represent a digested Org, after parsing and before it gets exported. Currently, the only way I see would to find a way to dump Emacs internal structures after Org parsing by Emacs (likely implemented through yet another exporter! ☺).

The most probable line of action is studying the syntax and reflecting it. Examples could illustrate the syntax, enlighten it, but are no replacement for a good reference documentation, I guess.

[wallyqs]

In case we are talking about the expected behaviors and not the actual results, maybe starting to to base from (test-ox.el)[http://orgmode.org/w/org-mode.git?p=org-mode.git;a=blob;f=testing/lisp/test-ox.el] would be a good to get an idea if the coverage then, well at least that is what I am planning for Org ruby from now...

[pinard]

wallyqs: Thanks for the link! :-)