emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* the "right way" to build OMPL export and import
@ 2013-04-24 20:25 Alexis Gallagher
  2013-04-26 21:30 ` Eric Abrahamsen
  0 siblings, 1 reply; 6+ messages in thread
From: Alexis Gallagher @ 2013-04-24 20:25 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: the "right way" to build OMPL export and import
  2013-04-24 20:25 the "right way" to build OMPL export and import Alexis Gallagher
@ 2013-04-26 21:30 ` Eric Abrahamsen
  2013-04-26 21:49   ` Nicolas Goaziou
  0 siblings, 1 reply; 6+ messages in thread
From: Eric Abrahamsen @ 2013-04-26 21:30 UTC (permalink / raw)
  To: emacs-orgmode

Alexis Gallagher <alexis@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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: the "right way" to build OMPL export and import
  2013-04-26 21:30 ` Eric Abrahamsen
@ 2013-04-26 21:49   ` Nicolas Goaziou
  2013-04-26 22:23     ` Eric Abrahamsen
  0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Goaziou @ 2013-04-26 21:49 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

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.


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: the "right way" to build OMPL export and import
  2013-04-26 21:49   ` Nicolas Goaziou
@ 2013-04-26 22:23     ` Eric Abrahamsen
  2013-04-26 22:36       ` Nicolas Goaziou
  0 siblings, 1 reply; 6+ messages in thread
From: Eric Abrahamsen @ 2013-04-26 22:23 UTC (permalink / raw)
  To: emacs-orgmode

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: the "right way" to build OMPL export and import
  2013-04-26 22:23     ` Eric Abrahamsen
@ 2013-04-26 22:36       ` Nicolas Goaziou
  2013-04-27  4:51         ` Eric Abrahamsen
  0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Goaziou @ 2013-04-26 22:36 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: emacs-orgmode

Eric Abrahamsen <eric@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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: the "right way" to build OMPL export and import
  2013-04-26 22:36       ` Nicolas Goaziou
@ 2013-04-27  4:51         ` Eric Abrahamsen
  0 siblings, 0 replies; 6+ messages in thread
From: Eric Abrahamsen @ 2013-04-27  4:51 UTC (permalink / raw)
  To: emacs-orgmode

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

> Eric Abrahamsen <eric@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...

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-04-27  4:45 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-24 20:25 the "right way" to build OMPL export and import Alexis Gallagher
2013-04-26 21:30 ` Eric Abrahamsen
2013-04-26 21:49   ` Nicolas Goaziou
2013-04-26 22:23     ` Eric Abrahamsen
2013-04-26 22:36       ` Nicolas Goaziou
2013-04-27  4:51         ` Eric Abrahamsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).