Live data from Hacker News

Pandoc

pandoc.org

181–190 of 298 posts

Re: Pandoc

#181
post #77

Earlier quoted context omitted.

Is there any reason for why you’re not considering AsciiDoc?

No such reason. I'm willing to try out AsciiDoc. I mean I did not try AsciiDoc until now because there are so many choices of input formats and the ones I've tried so far have been disappointing one way or the other. I talked about Org-mode rendering broken in edge cases. Same with Latex too. I see Pandoc has first-class support for its own Pandoc Markdown format. But the support for all other input formats seem patc…

Pandoc has no support for asciidoctor as an input format — you're expected to just use asciidoctor itself to convert adoc files (and there's no reason not to). Asciidoctor can do HTML and PDF, not sure about EPUB though.

Re: Pandoc

#182

The latest website I was asked to build is just Pandoc + Make. It works super well, it's very fast and decently flexible. I even do blog-like processing by just calling Pandoc several times.

I used to build my blog with Pandoc, make, and a little bit of Python/Jinja2 glue to generate indexes/tags/RSS. The amount of glue tends to get out of hand as the project's needs grow though.

Re: Pandoc

#183
post #30

Earlier quoted context omitted.

Codebraid[0] is another option for integrating code execution with Pandoc. I find myself using Quarto for building sites and Codebraid more for single documents. Both great tools building on Pandoc. -- [0]: https://codebraid.org/

Why do all these tools pretend that knitr / R Markdown never existed, and that they have invented some novel concept? I looked through the docs of Quarto, Jupytext, and now Codebraid, and none of them mention prior art. There's a long legacy here, it does nobody any good to disregard it. Maybe Knuth is well-acknowledged for his invention, but I think for instance Yihui Xie is a little under-recognized.

And knitr is built on the prior art foundations of Sweave....

Re: Pandoc

#184

Earlier quoted context omitted.

I also use Word for all my writing too, so wanted to defend you. People (tech people at least) have lost sight of the fact that writing should happen in "word processing software", and Word is the best-in-class. To people who say "Word sux", I say "That just means you don't know how to use Word properly". Writing any markup or markdown syntax in an IDE is a disaster for the creative process. Jack Kerouac used to type…

If you want to use Word, then that's great, but when you start saying what other people 'should' be doing then they're going to speak up. > writing should happen in "word processing software" Writing should happen where you are comfortable editing text. I am comfortable in same editor where I write code. > To people who say "Word sux", I say "That just means you don't know how to use Word properly". Writing any marku…

> Writing should happen where you are comfortable editing text.

For that particular context of text.

I write my code, notes, text and emails in vim. Some in markdown. But to this day, I still miss the incredible usability of LyX 1.x when writing pure long-form text.[ß] I could force all writing to occur within central 60% of the editable screen height [doable with vim but not as cleanly]. No whitespace or formatting issues, ever - set the document defaults according to my liking and it would feel "just right".

Proper rendering and visually correct editing of math formulas as part of text. Oh my. Fond memories of being able to type '\frac' and continue fitting in the values...

If it had had vim's search-powered navigation, it would have been nearly perfect. LyX 2.x was a step up in visual appeal and two steps down in raw usability. I've since picked up writing raw latex where I need good formatting, just because I could not make LyX 2.x bend to my taste anymore.

ß: Back on early 2000's, I wrote a book in LyX. As well as all my university course papers, including the master's thesis.

Re: Pandoc

#185

Earlier quoted context omitted.

I've translated HTML markup to Markdown, and from Markdown to LaTeX before fine-tuning the LaTeX, to produce PDFs for printing hard-cover books. Does Markdown have any way to specify eg "begin a chapter on a new page" ? I don't think this is really a thing in Markdown or HTML but I'm admittedly a casual Pandoc user.

If you are writing a book, presumably you would have each chapter in a separate markdown file. So, then you convert each chapter file to pdf, and then join the pdfs.

You can inline LaTeX chapter/section break commands even when processing Markdown, and in several ways (dropping \newpage directly in the content before chapters, using header templates, as YAML metadata in the Markdown file, even on the command line).

Google has many examples; one's here using a header file: https://medium.com/@sydasif78/book-creation-with-pandoc-and-...

More are here, including an example using the header-includes YAML metadata param: https://github.com/Wandmalfarbe/pandoc-latex-template/issues...

Re: Pandoc

#186

Earlier quoted context omitted.

My kingdom for proper markdown support in google docs. Just let me toggle between wysiwyg vs markdown. Collaboration at a tech company using google docs is comically painful at times.

+1 strong agree. I like Google Docs’ realtime collaborative editing, but the wysiwyg formatting (even if one has memorized the keyboard shortcuts) makes it hard to be fast the way I am in a Markdown-aware editor or vim. Plus I miss my vim motions!

I'd settle for a Markdown import. You could do your editing and writing of raw text in whatever you feel happy with, and then have gdocs transform it to its supposedly native format on upload.

Gdocs would then really only need to support the same semantics with underscores, asterisks, octothorpe heading levels and title sizes.

Re: Pandoc

#187
I do all my scientific writing in Markdown (SublimeText + JabRef for bibliography). In ST I have a macro that runs Pandoc to convert .md files to .odt/.odp, including images and formatted references. Wonderful program to work with.

Re: Pandoc

#188

Earlier quoted context omitted.

I have this same issue, and the same with `jq` and `GNU Parallel`. When you need them you need them, and nothing else quite works, but I have to re-learn them every time.

I outsource most of my esoteric `jq` syntax questions to ChatGPT. It does really well with them, usually turning up solutions that I'd struggle to munge together from several different google search results. I wonder how ChatGPT would do with focussed pandoc requests.

I'm not allowed to use chatgippity at work, sadly. But Ive heard a lot of people mention this so I might try it at home and see what's what.

Re: Pandoc

#189
post #87

Earlier quoted context omitted.

> If you find writing in a given dialect of Markdown or LaTeX or Org-mode is easiest, do that. I find Org-mode the easiest but like I said in my comment, the conversion quality is not great. Pandoc breaks a lot of stuff in Org-mode in edge cases. One example I shared in my comment was Pandoc breaking internal links. So by selecting something I find the easiest I have burned many hours of troubleshooting figuring out…

Unfortunately, the perfect is very much the enemy of the good here. Aside from HTML, I'm afraid that PDF and EPUB are very much driven by purpose-built tools designed to show interactively what it will look like as output. This means that they've both delved into a depth of subtle semantic differences that makes flawless output an extremely difficult task. Of course, practically, pandoc can resolve the vast majority…

Riffing on crafting pipelines by combining tools...

Org mode can also export html and markdown, so that's three potential pandoc inputs, with potentially different properties. All of which might be massaged before input. And in extremity, an org-mode parser permits emitting customized input. Then pandoc's parsing and filters permit altering the pandoc ast in flight. And the ast isn't hard (assuming comfort with ASTs), so if some other tool has templates and output one likes, one might skip the pandoc backend and emit it oneself from pandoc ast json. Rather than hoping to persuade that other tool to both accept and generate what's needed.

So for instance, last year I had a project written in a project-specific markdown dialect, kludged to pandoc-flavored markdown, parsed with `pandoc -t json`, and html emitted custom from the pandoc ast. With embedded directives from dialect to emitter. And html templates copied from non-pandoc tools. In a language with nice pattern matching (julia's Match), the emitter was a short page of code.

"Avoid reinventing wheels, but sometimes it's easier to assemble a satisficing custom vehicle, than to find and adapt a previously-built one."

Re: Pandoc

#190
post #183

Earlier quoted context omitted.

Why do all these tools pretend that knitr / R Markdown never existed, and that they have invented some novel concept? I looked through the docs of Quarto, Jupytext, and now Codebraid, and none of them mention prior art. There's a long legacy here, it does nobody any good to disregard it. Maybe Knuth is well-acknowledged for his invention, but I think for instance Yihui Xie is a little under-recognized.

And knitr is built on the prior art foundations of Sweave....

And sweave is built on noweb :)
Post reply on HN