4 ms·
> Markdown in an of itself isn’t powerful enough to satisfy the simple monkey brained developer like me who is only satisfied when the site looks good enough™.
by nine_k 7mo ago
> Markdown in an of itself isn’t powerful enough to satisfy the simple monkey brained developer like me who is only satisfied when the site looks good enough™.
Well, indeed, Markdown is an inadequate tool for that. Let the author use more powerful tools, be it HTML, LaTeX, SVG, etc.
Markdown is fine for its intended purpose: very light formatting, very simple header structure. If I were not that lazy, i would come up with something opposite to CommonMark, some MarkDownDown, that does away with alternative ways to format things, most escaping, and most advanced syntax. The goal would be to have an easy-to-implement, unambiguous, safe and simple subset good for use anywhere. Intentionally limited.
(For daily use I prefer Org Mode, due to its vastly superior support in my preferred editor.)
- xigoi 7mo ago> If I were not that lazy, i would come up with something opposite to CommonMark, some MarkDownDown, that does away with alternative ways to format things, most escaping, and most advanced syntax. https://djot.net/ https://djot.net/
- nine_k 7mo agoIt makes quite a few right calls, but still tries to not be a strict subset of Markdown, requiring e.g. a different editing mode.
- xigoi 7mo agoBeing a strict subset of Markdown would make it itpossible to achieve simplicity. From the rationale: > Rules for emphasis should be simpler. The fact that doubled characters are used for strong emphasis in commonmark leads to many potential ambiguities, which are resolved by a daunting list of 17 rules. It is hard to form a good mental model of these rules. Most of the time they interpret things the way a human would most naturally interpret them---but not always.
- nine_k 7mo agoIndeed. I'd go with dead simple rules. The below assumes whitespace or punctuation on either side: *bold* _italic_ *_bold italic_* _*also bold italic*_ Any other combination does not parse as formatting, and is considered literal text. Yes, this prevents marginally useful cases like putting an italic fragment in the middle of the word. I'd be fine with that.
- xigoi 7mo agoIf I’m understanding correctly, your rules are based on word boundaries? How do you define a word boundary?
- nine_k 7mo agoWord boundaries are a complex thing, especially in languages like Chinese or Japanese. Whitespace and punctuation are much less complicated, even if we take the full Unicode case. So the boundary where formatting is considered is between (whitespace | punctuation) and anything else.
- xigoi 7mo agoSo now you have to distribute a character class table in every implementation of your language, which is precisely what the author of Djot wanted to avoid.
- NetMageSCW 7mo agoSo y = x * 7 + b * c will be bolded in the middle?
- johannesrexx 7mo agoNo
- bloppe 7mo agoIf only you could just put html tags in the markdown whenever you need a bit of extra expressivity!
- spartanatreyu 7mo agohtml comes with baggage. --- If you're writing a parser, you might have text nodes, and bold/italics nodes which can contain each-other and text nodes. Example: - bold node -- italics node --- text node But if you add html support, you're going to run into strings like this: <b><i>text content</b></i> How easy is it for you to represent that? What about: not bold or italic <b>bold but not italic <i> bold and italic </b> italic but not bold </i> not bold or italic What about: </b> not bold <b> bold <b> bold again? </b> is this still bold? </b> what about now? <b>