Nicolas Goaziou <n.goaz...@gmail.com> writes: > Hello, > > Eric Abrahamsen <e...@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
