It kind of is, though. Markdown did not start out as a markup language, but as a tool for displaying what was then considered to be plain text which used certain popular style conventions. That is, people wrote "plain text" in markdown style for many years, on mailing lists, in newsgroups, and in doc files, long before the introduction of markdown.pl.
In mailing lists and discussion groups, they actually used * as bold marker and _ as italics. Something I wish markdown would have used, instead of ** and *.
Those punctuation marks make sense and came from old-old school notations for typewritten manuscripts. I remember them from my Strunck and White /Elements of Style/ book from English 1A (sorta-old-timer here).
Microsoft Office apps still by default apply those marks for you. Quite annoying when you are trying to send an email with a file spec and it bolds things like *suffix.*
Edit: and HN does it as well :)
Isn't it the other way? Plain text is markdown but markdown isn't plain text?
You're leveraging some semi-readable things[1] to inject into the document to have special meaning, but normally written[2] text will render just fine in markdown.
1. I say semi-readable because BS like image and link tags really stretch the bounds of "as someone would naturally write it".
2. Normally written here is carrying a fair amount of weight but the "obscure" symbols used in markdown (that aren't just plain text conventions anyways) are extremely uncommon in normal communication.
In a sense, sure. Plaintext input is completely valid markdown though. You can take text from any plaintext editor and paste it into a markdown input and it will render as HTML or XHTML that very much resembles what you copied.
Then, if you want lines, you can embed SVG in it. You could also draw in a box, use a tool like ImageMagic to make a PNG or GIF, encode that as base64, and embed it into the document as HTML source.
What the author has done is basically invent their own JSON-based syntax for Pic, Fig, or SVG and their own comment/template tag format.
> You can take text from any plaintext editor and paste it into a markdown input and it will render as HTML or XHTML that very much resembles what you copied.
This is very, very, very far from the truth. People get tripped up by accidentally invoking markup and thereby destroying their text all the time. You ever see unintended italic text and missing asterisks here? I sure do. Or on sites that do Markdown, ever talked about a generic type Foo<T> and had the <T> disappear? Or talked about __init__.py and got 𝗶𝗻𝗶𝘁.py? Or taken text where you used a single newline character for paragraph breaks, and had everything end up as one paragraph?
> Plaintext input is completely valid markdown though.
Only inasmuch as there’s literally nothing that’s invalid Markdown. If you take text that you wrote as plain, unformatted text, Markdown will routinely destroy it.
—⁂—
To address the chain of comments that brought us here:
• I spoke of Markdown because the author spoke of Markdown, and used Markdown syntax.
• Markdown is plain text? Depends on what you mean by plain text. Under stricter definitions, absolutely not. Under weaker definitions, only mostly, unless you want to say that HTML is plain text too, in which case sure.
• Plaintext is not Markdown? Certainly true. Most plain text won’t be too badly damaged by reinterpretation as Markdown, but a lot will.
Plaintext, as in text, won't get seriously mangled. Text with symbols, which I admit should fit in the general idea of a "plaintext file", will be interpreted potentially in ways not intended in a regular text edited document.
Italicized, bold, and underlined HTML text does pretty much resemble the purposes for which those symbols (asterisks, underscores) are used in text. Even bulleted lists and numbered lists are handled in a pretty straightforward fashion.
Where you see problems is when you're putting in footnote notations, equations, source code, and such. There are ways in both HTML and markdown to keep pre-formatted text for those cases. What the author has accomplished is not having a special notation for those, but also reinventing Pic, Fig, DOT, or SVG for simple images. It's done by requiring a game engine rather than using any of those prexisting tools.
Pic and Eqn are literally from the 1980s and 1970s, respectively. Pikchr (a Pic enhancement) is designed to be embeddable into markdown rather than troff, and could pretty easily embed into plaintext-with-template-tags like this. DPic is Pic-compatible and can produce Postscript, PDF, SVG, or image formats. As a bonus to the author of lines.love Pic-compatible tools already can take nested expressions in a slightly different format, and can also produce programmatically-defined shapes.
