|
|
|
|
|
by zimpenfish
1119 days ago
|
|
> Is that impossible with markdown? No, that bit is the simple bit. > you could probably design every control symbol in markdown as a switch You need a layered mode though - you can have bold, italic, monospaced, header and link all active at the same time - which means you've got 32 states right there. But also! If you do something like `# Header _*bold-italic`, that italic and bold don't apply because the EOL stops the header state and retroactively cancels those bold-italic attributes. But on a non-header line, `_*bold-italic\nstill bold-italic*_` works fine because EOL doesn't cancel them. But also also! If you mismatch the order, it won't match both. Or, at least in Marked 2, if you mismatch the order on both sides of a non-attributed word, that word will get the wrong styling (`_*with mismatched_* middle *_attributes*_`). In summary, Markdown parsing is a clusterfuck. |
|
Requiring like, a byte, for state is hardly a complex requirement.
> But also! If you do something like `# Header _bold-italic`, that italic and bold don't apply because the EOL stops the header state and retroactively cancels those bold-italic attributes.
And an IF statement or two.
> But also also! If you mismatch the order, it won't match both. Or, at least in Marked 2, if you mismatch the order on both sides of a non-attributed word, that word will get the wrong styling (`_with mismatched_* middle _attributes_`).
Fair enough, but you can't expect to get correct output if you put wrong data in, you are trying to italicize it twice. If the interpreteation was "either * or _ turns italics on/off" you'd also have not what you expected.
My complaint about markdown here is really that there are 2 ways to make italics and 2 ways to make bold text. "Just" having * for bold and _ for italics would on top of making parsing easy also make it clearer. Less typing too.