Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: ORG to POD translator

by MidLifeXis (Monsignor)
on Apr 07, 2011 at 16:35 UTC ( #898111=note: print w/replies, xml ) Need Help??

in reply to ORG to POD translator

First, don't take these in any way as criticisms, but more as opportunities to make it process a larger subset of the org files out there.

I really like that it is simple and does not have prerequisites, so it is able to parse simple org files without a large footprint. That being said, my org files are very seldom simple, and I rely heavily on data within drawers, properties (node, tree, and global), among other things. Additionally, you have started the ball rolling with some actual code.

  • See lisp/org-exp.el, around line 2167 (barring any major updates) for a better pattern for the BEGIN_SRC line. It should allow an optional ':' after the BEGIN_SRC, and it is case insensitive.
  • A link to Org::Parser is probably in order :-)
  • Placing this code on something like github or the like might help to have more hands to help.

That is all that I have at the moment. Hopefully I will be able to take a closer look at it later. Thanks for starting this moving.


Replies are listed 'Best First'.
Re^2: ORG to POD translator
by LanX (Bishop) on Apr 07, 2011 at 17:08 UTC
    Well I wouldn't mind if _you_ put it on git-hub! :)

    (this already took more time that I wanted to spend)

    I once started a thread "[emacs] converting perl regex into elisp regex", that could be of help for understanding the original format definition and parsing for updates in the lisp files.

    Those other features you want shouldn't be to difficult to parse, the question is what kind of POD should they produce?

    And how is the interface supposed to look like?

    If you have an agenda please define it.

    Cheers Rolf

      The closest thing that I would have for an agenda would be to have a defined format for the org file itself. I would like to see the org community adopt a format for the org file, and a set of core functions (dealing with manipulating files, nodes, and properties) that behave in a defined fashion. Beyond that, it is basically up to the interface / library how it behaves based on the content of the file.

      Update: It looks like someone else may have some similar thoughts.


        Thats quite abstract and overwhelming.

        IMHO formulating concrete use cases and goals is the first step for improvement.

        Producing POD is pretty concrete, and not far from being sufficiently done.

        What do you want to produce? Do you want to support all export formats emacs knows?

        I'm not such a heavy org-mode user like you are, you need to formulate your needs.

        Cheers Rolf

      I see in rereading this that my comment about the source for the emacs regexp was misunderstood. I did not mean to imply that all of the other block types contained in that regexp should be parsed, I was only commenting on the possible formats that a "BEGIN_SRC" block could take.

      The link to Org::Parser was a reference to the unlinked reference (now linked in a footnote), not an indicator that you should use it in this script.

      The suggestion for github was to make it more readily able to have patches applied to it.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://898111]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (9)
As of 2018-07-17 12:14 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (363 votes). Check out past polls.