321–328 of 328 posts
Earlier quoted context omitted.
Indeed. 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 it al ic fragment in the middle of the word. I'd be fine with that.
So y = x * 7 + b * c will be bolded in the middle?
Earlier quoted context omitted.
This also misses the point: multiple syntax markers for the same thing is the opposite of simplicity (though that's not the reason why Markdown will fail)
You have the wrong end of the stick. The point is simplicity for the user, not the developer of the parser. And for users, having two ways to get the same thing adds no complexity- they just pick one and use it.
This is the needless complexity you wished away
Earlier quoted context omitted.
It's also worth remembering that markdown tried very hard to encode conventions that were already used in Usenet, email, and other text media. A > to indicate a quote was widespread Usenet convention. Asterisks or underscores to indicate emphasis was also a common convention; both are legal because both were common. Double asterisk or double underscores to indicate really, really emphasizing something was also a comm…
Writing mark down linter, i am i nterested in - if you think that you requirements for markdown formatting could be encoded in (relatively) simple rules?
- Superscript with hat symbol (^)
- Hidden content (also known as spoiler tags, content warnings, click-to-reveal, etc...) with two pipe symbols (||) at start and end of hidden content. Interact with the content to show the content inside.
- Table syntax to show tabular data and align content with pipe, hyphen, colon symbols
---
After that, I'd look at the extensions that are only useful for the use-case you're targeting:
- Subscripting with tilde symbol (~)
- IDs, Classes and Attributes
- Task lists
- Sections / Containers
- Language labels for code blocks
- Math Support (mathml, latex, katex, etc...)
- Table of Contents / Footnotes
- Definition lists
- etc...
Earlier quoted context omitted.
> 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…
If only you could just put html tags in the markdown whenever you need a bit of extra expressivity!
---
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:
text content
How easy is it for you to represent that?
What about:
not bold or italic bold but not italic bold and italic italic but not bold not bold or italic
What about:
not bold bold bold again? is this still bold? what about now?
I strongly dislike flexible input like __Unambiguous___, *Unambiguous* I’m reminded of the time Microsoft allowed mistakes in html writing. They attempted to parse a wide variety of common user errors. The effect of this was no standard and nobody else able to write a Microsoft compatible parser. I dislike Nim lang because of this. At least Nim defined the specification. Still though I think it creates more cognitive…
Why does flexible input bother you? There’s more than one way to do it is more than motto, it’s how all human languages work. Or does speaking English really bother you?
Earlier quoted context omitted.
Yeah, * asterisks * for italic has always felt wrong to me. I can understand underscores if slashes cause confusion with file paths. *bold* and _italic_ would have been better.
I agree that using *asterisks* just feels wrong for italics, and are much better suited for bold. However, surely the _underscore_ is just perfect to visually indicate underlining? As for /slashes/, which would visually be perfect for italics, the only reason they conflict between italics and filepaths is the fact that in both cases they are expected to be used at the beginning and end of a word. Maybe using an unnat…
O, c'mon! That is clearly a giant heading in a display font, squeezed in the middle and wider at the top and bottom. (-;
Earlier quoted context omitted.
That is an unjustified over-generalisation. HTML markup is pretty readable (except when it becomes soup) and I read and write raw HTML documents all the time. I like it better than markdown. It's even more readable in a code editor that distiguishes tags from content.
Ask your grandmother to do the same.
Both of them.