Re: [O] the right way to build OMPL export and import
Alexis Gallagher ale...@alexisgallagher.com writes: Hi, I would love to be able to export org documents to opal, so that I can read them with the various commercial outlining apps on platforms without emacs -- e.g, iOS. The ideal thing would be if I could import OPML as well. Is anyone working on this already? If not, does anyone have any pointers on the right way to go about this, so that the work would go smoothly and be acceptable upstream? This seems like a good time to ask given the recent consolidation of export facilities around the internal parser org-element.el. I presume any OPML exporter should be based on that, correct? Is any one of the existing exporters a particularly clean example to work from? For OPML import, is org-element-interpret-data the best starting point? Alexis Hi Alexis, I guess the first step to making an OPML exporter would be figuring out how to export correctly to XML, which happens to be something I've spent a whole fourteen minutes thinking about. 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. 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 | | #+BEGIN_SRC emacs-lisp (org-data (headline My Great Playlist (etc, snipped because printing this makes a huge mess) #+END_SRC | | magic-happens-here | | #+BEGIN_SRC emacs-lisp (outline ((text . My Great Playlist)) (outline ((text . The Cold Cold Ground.mp3) (type . song) (f . Tom Waits - The Cold Cold Ground))) (outline ((text . Don't Eat the Yellow Snow.mp3) (type . song) (f . Frank Zappa - Don't Eat the Yellow Snow #+END_SRC | | xml-print | | #+BEGIN_SRC xml outline text=My Great Playlist outline text=The Cold Cold Ground.mp3 type=song f=Tom Waits - The Cold Cold Ground/ outline text=Don't Eat the Yellow Snow.mp3 type=song f=Frank Zappa - Don't Eat the Yellow Snow/ /outline #+END_SRC It's the magic that will take some doing, though! Eric
Re: [O] the right way to build OMPL export and import
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. Regards, -- Nicolas Goaziou
Re: [O] the right way to build OMPL export and import
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
Re: [O] the right way to build OMPL export and import
Eric Abrahamsen e...@ericabrahamsen.net writes: 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. I don't know well OMPL format, but IIRC, it needs an inner-template (which would handle opml, head, etc.), a headline transcoder, and a couple of objects transcoders (e.g., for entities) in order to properly export text attribute. Anyway, you don't need to use `org-element-parse-buffer' at all. Regards, -- Nicolas Goaziou
Re: [O] the right way to build OMPL export and import
Nicolas Goaziou n.goaz...@gmail.com writes: Eric Abrahamsen e...@ericabrahamsen.net writes: 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. I don't know well OMPL format, but IIRC, it needs an inner-template (which would handle opml, head, etc.), a headline transcoder, and a couple of objects transcoders (e.g., for entities) in order to properly export text attribute. Anyway, you don't need to use `org-element-parse-buffer' at all. Great, thanks for the tips. Sorry if I hijacked the thread a bit, anyway should be useful to the OP...
[O] the right way to build OMPL export and import
Hi, I would love to be able to export org documents to opal, so that I can read them with the various commercial outlining apps on platforms without emacs -- e.g, iOS. The ideal thing would be if I could import OPML as well. Is anyone working on this already? If not, does anyone have any pointers on the right way to go about this, so that the work would go smoothly and be acceptable upstream? This seems like a good time to ask given the recent consolidation of export facilities around the internal parser org-element.el. I presume any OPML exporter should be based on that, correct? Is any one of the existing exporters a particularly clean example to work from? For OPML import, is org-element-interpret-data the best starting point? Alexis
