The Markdown Mindset(hiltmon.com) |
The Markdown Mindset(hiltmon.com) |
Of course doing this bypasses the possibility of easily converting to HTML, but I've started many research papers writing in Markdown, which has less, let's say, "markup overhead" than LaTeX, previewing the results using pandoc's markdown2pdf utility. Then later when I'm ready to use the proper article template it's an easy step to convert to tex and insert it in the template. It's a nice way to initially not worry about formatting while writing the draft, but pandoc's TeX transparency allows to you insert figures and math-mode markup and still keep the rest of the document in markdown, so it's brilliant.
Also with a little regex script to change "section" into "slide" it's trivial to use markdown and pandoc for generating Beamer presentations, which is way nicer than writing them directly in tex, because of all the enumeration/itemize sections.
1) Proper reference support. In LaTeX you can use things like \ref{fig:foo} to insert autonumbers for things like Figure X and Table Y. (Which is awesome, because if you move a figure, you don't have to change all of your numbers around.) There's no Pandoc markdown equivalent, so this gets lost if I convert to e.g. HTML. I have to work around this with a script that looks for this LaTeX snippet and does the counters before passing to Pandoc.
2) Better footnote output for LaTeX. Right now, if you use a [^foo] footnote mark twice, you will get two \footnote{}'s in your LaTeX (and therefore a repeated footnote message in your output) instead of a \footnotemark for the second one.
3) Better metadata. Both Jekyll and MMD are so much more flexible about the metadata you add at the top of a document; Pandoc seems to think the only items I'll ever need are author, title, and date. If I could only add things like addresses, enclosures, salutation lines, and extra variables my templates could adjust to, I could produce more sensible templates for formats like business letters.
If Markdown were just a single language, then sure, it’d be nice to have a more precise specification, and a cleaner Word-of-God implementation. But with all the slightly different implementations that now exist, Markdown has become less a language and more a language family. It’s just not useful to talk about standardisation, because it isn’t possible now, and we can’t go back to 2005 when it might’ve been.
Besides, the Daring Fireball implementation is hairy only because it’s designed to “just work”. The handling of “special” cases is the very thing that made the original Markdown so user-friendly and tolerant to variation. That is what Markdown is all about, and why it has become so popular in the first place.
More than a language, it’s a culture—a culture of getting things done without worrying about all the details of formatting. And that, I think, is the point of the article.
[1]http://fletcherpenney.net/multimarkdown/ [2]http://github.github.com/github-flavored-markdown/
I'm not sure it's got to do with web-orientation, reStructuredText has targetted a number of builders from the start, yet does not have a native pagebreak directive (you either need to use an extension, or use raw passthrough to the latex builder)
I have reverted recently to using RTF a lot for writing work notes, not feeling great about it, but there is a real convenience factor because OS X plays nicely with RTF for Finder instant view and using TextEdit. The bulk of my day to day (non-programming) writing is simply writing out copious daily work notes documenting everything that I do for my customers. I have found that being able to lightly style especially important notes is a large enough advantage to forgo the simplicity of plain text. Also, RTF pastes well into GMail if I want to send a styled text email (which I seldom do).
Based on reading this article, I may try the experiment of keeping my work notes for a single customer in plain text + markdown. The Marked OS X app looks pretty nice, but I am concerned that having two windows open (for editing and for viewing) might slow down what is now a very low ceremony activity.
Without even delving into Sphinx's extensions.
Here is a footnote reference,[^1] and another.[^longnote]
[^1]: Here is the footnote.
[^longnote]: Here's one with multiple blocks.
https://github.com/leeoniya/reMarked.js
the stated goal is to integrate into existing WYSIWYG html editors to produce markdown output. kind of like Markdownify, but on the client.
yay markdown! :D
Markdown is exactly what we needed but there weren't any good JS WYSIWYG editors available, so I hacked one together.
Two opposing points: (1) on reddit, I'll often check the markup result, going back and forth (esp checking URLs - probably less important for other writing), and that seems inefficient. I did the same with LaTeX; (2) when I read the text in the rendered format, I'll pick up different typos, perhaps because the line-spacing and font are different and so my eyes parse it differently (like that trick with "of" doubled at end and start of a line).
For a year, I used a homegrown markup language for uni notes. It was fun to use, seemed helpful, but I think was primarily self-indulgent. Maybe I should try it again - I'm currently using either plaintext for documentation (which isn't really clear enough); or open office Word (which takes forever to startup, doesn't feel accessible (can't just cat or head or tail or more or less or grep it), has non-vi keybindings and generally is a pain (though I complement their job of copying MS Word).
Finally - I'm kinda surprised at markdown's success (and it really is successful). I would expect WYSIWYG to be more user-friendly. I think one factor is that markup is optional in the context where it's been successful (like reddit). In other words, it may be "successful" because (1) it's not actually needed or used much (I mean, typos/grammos are endemic online, right?) (2) it has the gentlest possible learning curve if you do want to use it. Does this mean it would be terrible at more serious uses? Or that it is ideal to disrupt incumbent formatting methods? (disrupt defined: "initially worse at key features, but has features appealing to different users such as convenience/price/accessibility").
It would be interesting to measure the percentage of reddit comments that actually use any markdown at all. I think it would be very low, something like 1-2%
BTW: You had my vote at ZX81 is that wrong?
Brackets are reserved delimiters in RFC3986 (etc) whereas angle brackets are recommended for delimiting URIs.
Reluctantly, I agree that plain text documents are the way to go. I used to be a FrameMaker user.
While much of this was possible before, Markdown is so much easier for writing a programming/tech blog.
My biggest complaint with the various lightweight/plaintext markup formats is the sheer variety and incompatibility of their markup syntax. Pandoc goes a long way to being able to convert the more popular ones easily, but it would have been nice if there had not been so much gratuitous re-invention of the wheel. It's kind of sad that the MultiMarkdown table format is incompatible with the tables in reStructuredText.
Markdown's default behavior of disregarding line breaks has two benefits: (1) you can keep your lines short without breaking paragraphs apart, and (2) putting each sentence (or long clause) in its own line plays very nicely with version control systems.
CSS is so much more designer-friendly than LaTeX stylesheets...
A *simple* example.
pre. 10 print "hello"
20 goto 10
And that's that, except for @inline@ code.
I find Markdown best for generating documents/documentation, and Textile best for generating styled web copy.
The last time I tried Textile, the "pre." prefix didn't produce the desired effect. But maybe that was a problem with that particular website's CSS. Thanks for correcting me there.
> Markdown can feel limited in its access to readable HTML style indicators.
Fair point. Textile seems to be optimized for producing styled HTML, whereas Markdown tries very hard to make the user forget about the fact that they're using a markup language at all. Even its name suggests that it's meant to be an anti-markup-language markup language.
For example, if you use "pre." in Textile, you're saying that the text should appear exactly as entered (because HTML ignores whitespace by default). Similarly, class attributes are only meaningful in HTML+CSS. On the other hand, when you indent a code block in Markdown, you're not saying anything about presentation, you're just making the code block look nice in plain text while also making a semantic point that the indented block is computer code. Gruber has consistently vetoed any feature that would make Markdown look less like plain text and more like HTML. You would think it odd if a plain text document contained things like "pre." and "(class)".
This makes it easy to compile Markdown to non-HTML formats like LaTeX and even ODF, which MultiMarkdown does. But I can see how Markdown's obsession with plain-text purity can be a limitation if you're trying to add style to a document that you know will be compiled to HTML.
pandoc -t beamer -o presentation.pdf