Re: the "right way" to build OMPL export and import

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I'm not sure the general export engine is going to be of much use,
>> since XML is so completely flexible, but you'll definitely want to
>> build it on top of the internal parser.
>
> It would be a bad idea not to use the export framework, unless you want
> to reinvent the wheel (e.g., re-implementing skipping of :noexport:
> tags).
>
>> Luckily, the parser turns an org subtree into a parse tree, and the
>> function `xml-print' turns a parse tree into XML. They're not quite the
>> same parse tree, but I guess you'll want to do something like this:
>>
>>
>> #+BEGIN_SRC org
>>   ,* My Great Playlist
>>   ,** The Cold Cold Ground.mp3
>>   :PROPERTIES:
>>   :OPML_TYPE: song
>>   :OPML_F:   Tom Waits - The Cold Cold Ground
>>   :END:
>>   ,** Don't Eat the Yellow Snow.mp3
>>   :PROPERTIES:
>>   :OPML_TYPE: song
>>   :OPML_F:   Frank Zappa - Don't Eat the Yellow Snow
>>   :END:
>> #+END_SRC
>>
>>
>> |
>> |
>> org-element--parse-elements
>
> Please use `org-element-parse-buffer' instead. As the two consecutive
> hyphens suggest, this is an internal function.

I was hoping you'd jump in!

Would you suggest an export backend that only handles headlines (other
elements are a no-op)? I suppose you could just write org-opml-headline
to read properties and return XML chunks, and then you wouldn't have to
use `org-element-parse-buffer' at all.

E