Emphasis (italics), strong (bold), also links and images

[wooorm]

Originally reported by @kentcdodds at #1

Emphasis and strong in markdown are typically rendered bold, italic. This grammar does not do that. I thought I’d open this issue to allow a discussion around it, and to explain why.

This is a “feature not a bug” kinda thing. But it’s important and different. So I’m very open to discussing it.

This different handling is inspired by how other markup languages work.
In HTML or JSX, when you write <strong>whatever</strong>, or <a href="#">whatever</a>, things do not become bold or underlined either.
You can also write asd <strong>asd in them and have that be marked, which I think is nice.

Making things actually bold, actually italic, is somewhat nice and useful. But:

• it can’t highlight while you type (asd **asd from above), which is important in editors.
• it doesn’t support line endings (limitation of how TextMate grammars work):

  asd [asd
  asd](https://example.com)

• it’s impossible to get correct, the algorithm for matching [, ], *, and _ together is so complex that it can’t be put into a regex

Which is why this syntax is more like other markup languages and doesn’t show bold or italics.

[remcohaszing]

I really like this feature. It gives markdown editing a bit of a WYSIWYG experience.

I recognize the limitations you mentioned from both the current markdown highlighting experience in both VSCode and Discord. However, if such popular tools have this issue already, maybe most people don’t find it such a big deal.

Also my Monarch language from microsoft/monaco-editor#3096 supports multiline emphasis/strong text, but it does have other limitations. Maybe there’s something in there you can use for inspiration, but probably not.

[kentcdodds]

I use markdown (and MDX) in my educational material and people often read it in their editor. So having inline highlights for stuff like this is actually rather important for them to see the emphasis visually in their editor. But I understand if that's not reason enough.

[wooorm]

So having inline highlights for stuff like this is actually rather important for them to see the emphasis visually in their editor
— kentcdodds

I want to stress that things are highlighted. Those asterisks or underscores are marked.
Additionally, one main benefit of markdown is that it mostly looks like what it means even when it isn’t rendered. To illustrate, this *and* that, still looks stressed without any highlighting. And even more so if the asterisks are highlighted.

It gives markdown editing a bit of a WYSIWYG experience.
— remcohaszing

That may not be a good thing, markdown is also in my opinion about meaning, not just about how it looks with bold and italics.

However, if such popular tools have this issue already, maybe most people don’t find it such a big deal.
— remcohaszing

I wonder. Because with the new MDX highlighting, I got responses that people didn’t know blank lines could be used in ESM. Similarly, I assume that people didn’t know they can indent MDX. And several other things that work fine in the language, but just weren’t highlighted.
I assume that this broken highlighting around line endings and nesting actually does affect how people use markdown/MDX, a lot.

Also my Monarch language […] supports multiline emphasis/strong text […]
— remcohaszing

That’s great but it isn’t possible in TextMate languages. They work per line. Or there is no backtracking. Two choices: a) either you don’t mark a *b\nc* d. b) you make everything after the start in a *b\nc d. orange/bold/whatever.

[kentcdodds]

Honest question, why highlight headings then?

[wooorm]

Because they can be highlighted, properly, according to CommonMark. No trade offs.
But I think the word “highlight” is vague here. Everything is highlighted! The special characters for emphasis/strong/links/images are highlighted.

There are limitations at play for emphasis/strong/links/images. In how markdown must be parsed and how highlighting works. Which means you can’t get them correct. So, there are trade offs.

• You can either highlight things that actually don’t work and not highlight things that do work (which is what happens in other places)
• Or you can highlight all the things that might work (which is the current state)

I think that’s more in line with what syntax highlighting is for: it doesn’t bring guarantees that your code will run. It’s not a linter. It’s also supposed to do things while you are typing.

[remcohaszing]

Several programming languages support multiline strings, including nested syntax for variables. Is this somehow different from highlighting markdown emphasis / strong?

JavaScript uses a single backtick as delimiter, more similar to markdown emphasis:

export const string = `
multiline
string
${withVariables}
`

Python uses triple quotes (""" or '''), more similar to markdown strong:

string = f"""
multiline
fstring
{withVariables}
"""

[wooorm]

And what happens in those languages/grammars when you don’t do the final "?
That’s the problem. There’s no backtracking across lines. Everything becomes a string. See my choice b earlier: #4 (comment).

[remcohaszing]

People who run into this issue may be interested in the remcohaszing.vscode-markdown-decorations VSCode extension.