Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

pandoc already supports opml #1

Closed
jgm opened this issue Jan 13, 2015 · 3 comments
Closed

pandoc already supports opml #1

jgm opened this issue Jan 13, 2015 · 3 comments

Comments

@jgm
Copy link

jgm commented Jan 13, 2015

Given that pandoc already supports opml, you might want to make the rationale for the project clearer in the README.

% pandoc -t opml -s

---
title: Demo Document
author: Eric Davis

---

# Hello World!

This is a child of the "Hello World!" header.
<?xml version="1.0" encoding="UTF-8"?>
<opml version="2.0">
  <head>
    <title>Demo Document</title>
    <dateModified></dateModified>
    <ownerName>Eric Davis</ownerName>
  </head>
  <body>
<outline text="Hello World!" _note="This is a child of the &quot;Hello World!&quot; header.&#10;">
</outline>
  </body>
</opml>

The output is a bit different from yours. (The level attribute is not used, only headers produce outline elements, and non-header content is attached to headers via the _note attribute.) If you think pandoc's OPML output is not optimal, why not contribute bug reports or patches to pandoc?
@edavis
Copy link
Owner

edavis commented Jan 13, 2015

That's a fair critique.

I did start out using pandoc's OPML writer but the decisions it makes (e.g., only headers getting outline elements and the addition of the _note attribute) did not work for my use case. However, there's nothing wrong those decisions — they're just different from how I would have done it. Not really fertile ground for a bug report, I felt.

A custom Lua writer didn't work with nested lists and I don't know a lick of Haskell. Hence this approach of doing it in Python via the JSON AST.

I have no interest in fragmenting what you're trying to do with pandoc. This approach just felt like the quickest way to get where I wanted to go and I was pretty proud of how it turned out and thought I'd toss it out there.

If there's enough interest in this style of OPML, I'd be happy to help contribute patches so it becomes the default pandoc OPML writer.

@jgm
Copy link
Author

jgm commented Jan 13, 2015

OK, that's great -- if you think pandoc's approach is not broken, but just prefer something different, then this seems a good way to go. I don't really know much about OPML myself, or how it is generally used, so when I saw your output I thought we might have been doing it wrong. I wrote the OPML writer based on a pretty quick reading of the specs on line.

If you do want to make suggestions for pandoc's OPML writer, it would make sense to do it on pandoc-discuss, where other users can chime in.

@edavis edavis closed this as completed Apr 2, 2016
@huyz
Copy link

huyz commented Jul 24, 2022

This app certainly makes a lot more sense to me than what pandoc does by default. For instance, the output from this app would be import into logseq much better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jgm @huyz @edavis