Status and quality of Org-reader

Status and quality of Org-reader

[c.buhtz-OA1p21XQzgd4Eiagz67IpQ]

Hello,

I was pointed to pandoc because it might be usable as an org-file 
parser. Technically I'm interested in reading org-files and get them 
back in JSON format.

Some quick n dirty tests are promising. I'm maintainer of an 
org-to-html-converter application (I assume advertising it isn't suited 
here.) and do most of the parsing myself. But I'm at a point to think 
about refactoring the parsing or finding a better solution.

Before I throw half of my code into the trash I would like to learn and 
hear more about the current status of the org-reader and how you rate 
it?

I was also looking into the bug tracker and only found some minor 
problems with org reading. All problems I found I can handle and 
workaround with my own code.

Do you have any further suggestions about the org-reader part of pandoc? 
How many people in the pandoc project working on the org-reader part?

Kind
Christian Buhtz

Re: Status and quality of Org-reader

[Albert Krewinkel]

Hi Christian,

c.buhtz-OA1p21XQzgd4Eiagz67IpQ@public.gmane.org writes:

> I'm maintainer of an org-to-html-converter application (I assume
> advertising it isn't suited here.) and do most of the parsing myself.
> But I'm at a point to think about refactoring the parsing or finding a
> better solution.

To the contrary, please do. I like to learn from other projects, and
feel that it's very important to acknowledge when there are tools that
do a better job at some conversions.

> Before I throw half of my code into the trash I would like to learn
> and hear more about the current status of the org-reader and how you
> rate it?

I'm obviously biased in my views, as I wrote most of the code for the
org reader. So take this with a grain of salt.

I believe we're doing a solid job, but it's nowhere near perfect. Org is
powerful and complex, and it's not always easy to match org concepts to
pandoc's way of handling things. Prime example: input handling that
depends on the output format, as seen in issue #5454.
https://github.com/jgm/pandoc/issues/5454

OTOH, the writer holds up quite well when it comes to #+OPTIONS handling
and metadata processing. Most markup-parsing is good, too.

The lack of a formal syntax definition and a constantly changing
reference implementation make org a moving target.

See also https://pandoc.org/org.html for an overview of what pandoc can
and cannot do.

> I was also looking into the bug tracker and only found some minor
> problems with org reading. All problems I found I can handle and
> workaround with my own code.

Some of these small things are quite hard due to the way pandoc works.
Other tickets would require just a little bit of time and could possibly
be fixed quickly; I'm not sure.

> Do you have any further suggestions about the org-reader part of
> pandoc? How many people in the pandoc project working on the
> org-reader part?

It's mostly me, with jgm fixing bugs and adding features there, too.

The org reader was the first real-life Haskell code that I wrote a
decade ago, but I tried to keep it maintainable. It's ok code IMHO.
Org is not a priority for me right now. I'd like to extract it into a
separate package some day, which could also help to fix a few issues,
but don't have any concrete plans yet.

Best,
Albert


-- 
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124