Markdown was originally a loose formalization of how people already wrote text only emails. It was how _people_ wrote, not how to optimize for the computer.
Maybe Markdown just hit the sweet spot. But I actually suspect it's something else: as soon as it's very convenient to have machines ingesting and producing a language, it becomes tempting to create tooling that is unnecessarily strict in what it will accept while at the same time spitting out markup that is unusually difficult for humans to read. A sort of specialized violation of the Robustness Principle.
The most famous example of this was probably XHTML, but even HTML5 suffers from it. And so we end up with stuff like Markdown because HTML tooling is too hostile to work with directly, and AsciiDoc because DocBook XML is similarly awful. They don't have to be, but...
Not sure, but isn't using _ instead of the more intuitive /italics/ a big mistake on the syntax side?
... in fact I just tried it and underscore apparently works in WhatsApp, TIL.
OTOH /italics/ reads to me as a regular expression, which ... is apparently not what you meant.
(as ever, "intuitive" varies wildly between people, and the trick is to pick the option that's intuitive for the highest possible percentage of your expected user base)
What's that wild intuition of underscores???
Also, why would you ever read it as a regex in a human /text/ markup language?
Plus underscores get used -lots- of places for italics; I've yet to see the / form in the wild.
A markup language being (as here) used for technical purposes can easily be interpreted according to geek writing conventions.
Em is just another bad term - which of the emphasis styles do you mean?
Re popularity - so what? How does widespread bad turns into intuitive good?
Bear notes used / for italics, also Orgmode (is that geek enough for you?)
You have you know the fact that actual underlining had been traditionally used as a substitute for italics in hand-written and typewritten papers.
As in, in a citation, when you give a title of a book, you underline it, unless using a word processor with fonts, in which case you use italics.
Learned this in high school.
When was the last time you saw underlines in a book that weren't added by a previous reader?
Underlines are bad typography that should be used sparingly, if ever.
Surrounding text with underscores to indicate italicization is intuitive to anyone who is familiar with that convention.
Personally, I find surrounding text with forward slashes exactly wrong for italicization, because I mentally apply a skew-transform to the text to make the slashes into vertical lines, which leaves the text itself slanted in the wrong direction. Backslashes would make more sense, and also avoid looking like regular expressions. But literally no one uses that convention and we do not need a new one.
Also, this /convention/ already exists and used, despite its low popularity (eg orgmode or Bear note app), so you're also literally wrong here
Also, intuition is "understanding without conscious reasoning," so remembering a convention IMO counts.
Consider e.g. parental intuition of noticing subconsciously it's too quiet and immediately going to find out what the kids have done.
For UI, consider the floppy disk icon often used for 'save' - it's considered intuitive because the vast majority of users already recognise it without having to think about it, even if they've never had a system with a 3.5" drive themselves.
On the other hand, if you know that _ is __underline__, - is --strikethrough--, then you can acquire knowledge (guess) that / is /italics/ because the principle is the same - formatting text follows symbol's shape (though it's not a perfect mach since / transforms text, not adds new symbols unlike _ or - ). But that's still intuition (* for bold would not fit here)
The other bad analogies don't help resolve it, so best stick to the topic
I appreciate that you don't find the analogies convincing, but they do express how I (and many others) see the situation, and declaring it a failure to stick to the topic because it doesn't fit how -you- see things is unconstructive at best.
<table>
<tr>
<td>first row, first column
<td>first row, second column
<td>first row, third column
<tr>
<td>second row, first column
<td>second row, second column
<td>second row, third column
</table>
| first row, first column | first row, second column | first row, third column |
| ------------------------ | ------------------------- | ------------------------ |
| second row, first column | second row, second column | second row, third column |
| first row, first column | first row, second column | first row, third column |
| ------------------------ | ------------------------- | ------------------------ |
| second row, first column | exceptionally long second row, that makes second column look worse | second row, third column | {main
{h1 Title}
{p
Paragraph 1.
{{a {href google.com}} Here is a link.}}
{p
Paragraph 2, now with {b bold} text.}}
Replace the braces with parens and you can parse that into a tree with only a handful of lisp macros.
(define (code-block file-name)
{pre {{code {class block}}
#(cmd "highlight" (thisdir (string-append "posts/" file-name))
"-O" "html" "--inline-css" "--fragment"
"--line-numbers" "--line-number-length" "3")}})
{a {b} #c #@d} => `("a" ("b") ,c ,@d)
{a {b}c} => `("a" ("b") join "c")FWIW, my first static blogging system (circa 2003) did almost exactly the same thing you are doing (except that I used `[]` for lists, not `{}`). IIRC, it was maybe 5-6 macros+functions (and some readtable magic) to turn every `[foo ...]` into `<foo> ... </foo>`, with support for attributes using `:name=value` syntax and a list of exceptions for non-closing tags such as `<br>`, etc.
I redid something like that recently, in C, and it turned out to be unreasonably larger to write than in Clisp.
TBH, these days it's better to simply stick to markdown, because the tooling is much better (previews as you type, tools to automatically generate the html, inline HTML for what markdown won't do, etc).
Also, no one has implemented a really good experience for writing HTML, not for webpages, but simple documents. It could be really easy to write HTML mostly by hand if an editor could dynamically convert Markdown-like syntax into HTML tags on the fly. That way, the resulting document is definitely HTML, and not up to the interpretation of some flavor of Markdown.
Such an editor can also do things to try and soft-preview what emphasis the HTML represents. Here's an example of an experiment I worked on in this direction a long time ago: https://codepen.io/Ravenstine/pen/gyMVNx
^^ Never mind the pompous attitude I had when I wrote the placeholder text for it.
Using an XML specification of your choice, working from a simple desktop computer, and with no money for fifty thousand dollar "end-to-end publishing solutions", perform the following: publish a document that uses conditional processing to show two different outputs for two different audiences while using a shared set of document components.
<kitchen_timer/>
What did you end up using? Anything neat?
I'm going to bet you don't find anything at all.
The tooling in XML publishing is weird, locked down, horrible, or all three plus some. Plus a lot. So, even if we pretend XML publishing is the bee's knees, it loses the speed test, it can't work on vanilla computers/requires admin rights constantly, and new writers train up on Asciidoc, from zero, in four hours. At a glacial, defense-industry-standard-for-fifty-year-old pace. Git probably provokes more existential crises in training than the markup does. Nothing compared to the business side, of course, but this is the defense business, and it's all madness.