Ask Slashdot: Do You Use Markdown and Pandoc?

BartlebyScrivener writes "I am a author, screenwriter, law prof, and a hobbyist programmer. I love MacVim and write almost everything in it: Exams, novels, even screenplays now that Fountain is available. I use LaTeX and WordPress and so on, but several years ago I discovered Markdown and the wonderful Pandoc. I searched Slashdot expecting to find lively discussions of both Markdown and Pandoc, but found nothing. Do Slashdotters look down their noses at these tools and do their work in HTML and LaTeX? I can't imagine computer geeks using Word instead of their favorite text editors. If not Markdown and Pandoc, what tools do Slashdotters use when they create documents that probably need to be distributed in more than one format: HTML, PDF, EPUB or perhaps even docx?" And then there's DocBook, LyX, and a host of other markup languages. What do you use, in what context?

Comments

Yes

[Ardeaem]

I used to use LaTeX for everything, but I have switched to markdown for presentations, papers, tech reports, and even everyday statistical analysis (probably, they'll turn into tech reports anyway). LaTeX is way too finicky for everyday use. markdown doesn't completely fail over a misplaced character, while LaTeX will. Of course, you're giving up a lot of power by moving to markdown, but I find for most things markdown provides a good balance of usability and flexibility. I still use LaTeX for papers I'm going to submit to scientific journals, which is where I need the features of LaTeX.

I use the Rmarkdown flavor of markdown.

I use emacs

[foobar bazbot]

Because it has C-x M-c M-butterfly.

Re:Yes

[buchner.johannes]

LyX for reports and paper writing, with some raw LaTeX sprinkled in. I have a short python script that can merge multiple documents so I don't have extremely long bulks of content. And there is the python environment for LaTeX, which is awesome with sympy and matplotlib.
LibreOffice for quick documents perhaps with images for a quick WYSIWYG. There is no reason to do everything in text, for some (many?) things the feedback loop is just way too long.
reStructuredText for code documentation, anything that should be readable from command line, but also can be used to make pretty html websites. Sphinx helps. rst exports into plenty of formats via docutils (just expand for rst2* commands).
Converters to epub for stuff I want to read on my ebook reader (from Calibre).
For the text formats my usual editor is gedit. Simple and plain.

It doesn't matter much if you prefer Markdown or rst, that's like arguing which wiki has the best syntax. There are plenty of utilities that can cross-convert and export (pandoc is one of them).

Scrivener

[Tridus]

If you're writing a novel, a tool like Scrivener is a lot better than a text editor of any particular sort. It's designed for writers and makes it easy to do things like keep track of and organize all your notes, which if you're writing a novel is going to be far more important than whatever command is used to change the font.

Re:Yes

[TeknoHog]

LyX for reports and paper writing, with some raw LaTeX sprinkled in. I have a short python script that can merge multiple documents so I don't have extremely long bulks of content.

\input{file.tex} is your friend, it's basically the latex equivalent of the include statement in many languages. It's particularly nice if you have a simulation, gnuplot etc. generating a splash of latex that you want to integrate in the full paper.

Re:Markdown is gaining popularity again

[gd2shoe]

That said, I afraid that most people still would prefer wysiwyg systems, as it easier to use than 'feel like a programmer' when using weird codes such as HTML, MarkDown, bbcodes, MediaWiki etc.

"Feel like a programmer" isn't the problem. Knowing that something is technically correct, but being unable to instantly verify that it is aesthetically pleasing is a major hangup. Unless you're making a professional report, or writing a book, there's no benefit to: hand-encoding a text, rendering it, editing the code, re-rendering it, tweaking the code, re-re-rendering it, tweaking the code again, re-re-re-rendering it... ad infinitum. In order for all that work to be worth it, the project must call for absolute perfection.

For a vast majority of writings out there, "good enough" is good enough.

(In today's day there really is no good reason why we can't have LaTeX quality wysiwyg. Computationally expensive, blah, blah, blah. We've got very, very fast computers on every desk today. Caching, and clever use of pre-rendering would permit a vast majority of changes to be rendered in real-time.)

Re:Yes

[Will.Woodhull]

Since wiki syntax has been mentioned, I'll jump in.

I now use wikitext for nearly all my writing, usually using gedit as the editor. My writing does not require the level of formating that LaTeX and its ilk are capable of. A good portion of my writing is in collaboration with others, and I want to grow that percentage since the text is consistently better when more than one person is stirring the word pot.

I've used several wiki engines since about 2003. At the moment Dokuwiki is my favorite: it has good ACL security, it handles embedded images and files okay, and it produces clean HTML5 pages. Mostly it behaves like Markdown in the way it gets out of my way when I'm using a plaintext editor.

An advantage of Dokuwiki and wikitext is that the semi-wysiwyg browser editor allows wider collaboration and effective proof-reading, by persons who don't want to learn a mark-up language, even a simple one.

When I need to do a brochure, business card, or other authoring task which is more about presentation than writing, then I use other tools. Inkscape is good, and I have done posters and slides in Gimp with little effort. But that is more about publishing than writing.

Re:not about CPU limitations, it's about grep + Em

[gd2shoe]

LibreOffice has its uses, but you can't grep .odt files.

Depends on what you're doing. You can't use grep, specifically, but you can search by regular expression in LibreOffice.

(Actually, instead of "LaTeX quality wysiwyg", which sounds like you want software other than Latex, but which gives equal quality, you probably meant to say "wysiwyg LaTeX". If that's the case, I agree...

That's one way to slice it, but not the only way. I think publishing has an unhealthy relationship with LaTeX. Markup languages have come a long ways since 1980. Why are we so stuck on this one? Another language that is (1) more human readable (2) easier to machine parse (3) renders to equal or better quality (4) is wysiwyg friendly, should be quite possible.

Re:Markdown is gaining popularity again

[TheRaven64]

You can fix it, but I agree that it usually puts it in the worst possible place. The problem is that TeX uses an elegant dynamic programming model to determine where to break lines in a paragraph, but uses a greedy algorithm to do page layout. Why? Because the PDP-10 didn't have enough RAM for the dynamic programming tables that would be required to do elegant page layout on a typical document. On a modern computer, even if it takes 2-3MB for the tables, you most likely have a single image in the document that is bigger than that (in early TeX, images had to be added afterwards in a separate compositing phase after you sent the typeset document to the printer, because computers weren't powerful enough to handle nontrivial images).

I tried implementing the TeX linebreaking algorithm for page layout in some naive (unoptimised) Objective-C a few years ago and ran it on a 900-page book that I'd written. Even then, it took under a second to run on the laptop I had at the time. There's no reason not to do it now.