Markdown: Preserve non-breaking spaces in inline code

[leafac]

Since #3320 non-breaking spaces are preserved in Markdown prose, but they still aren’t preserved in inline code, which would have been useful to avoid line breaks in things like x = 2.

In the listings below ␣ represents a regular space, and • represents a non-breaking space.

Prettier 1.18.2
Playground link

--parser markdown

Input:

normal␣space

non-breaking•space

`normal␣space`

`non-breaking•space`

Output:

normal␣space

non-breaking•space

`normal␣space`

`non-breaking␣space`

Expected behavior:

normal␣space

non-breaking•space

`normal␣space`

`non-breaking•space`

[alexander-akait]

/cc @ikatyang

[ikatyang]

It seems we should only process normal whitespaces (0x20), tabs (0x9), and newlines (0xA, 0xD):

prettier/src/language-markdown/preprocess.js

Lines 31 to 41 in 2314640

	function transformInlineCode(ast) {
	return mapAst(ast, node => {
	if (node.type !== "inlineCode") {
	return node;
	}
	return Object.assign({}, node, {
	value: node.value.replace(/\s+/g, " ")
	});
	});
	}

[leafac]

I think we should leave inline code untouched, because we don’t know in which language it is so anything we do may break it. Suppose, for example, that I’m writing Markdown to document Prettier, and I want to write about how Prettier would convert multiple tabs.

[ikatyang]

According to the CommonMark spec "Line endings are treated like spaces", newlines are always valid to process. As for the whitespaces and tabs, it is hard to decide if we should process them given that browsers typically render them as single spaces, or should we respect the htmlWhitespaceSensitivity option in this case?

[leafac]

Yes, you’re right. Normal whitespaces (0x20), tabs (0x9), and newlines (0xA, 0xD) may all be processed. I don’t see a point in respecting htmlWhitespaceSensitivity in this case.

[ikatyang]

Those whitespaces are sensitive if you apply CSS (e.g., code { white-space: pre; }) on the rendered HTML.

[leafac]

If we were to consider that case, then we couldn’t change whitespace anywhere because of, for example, p { white-space: pre; }

[jellopuddingstick]

Just wanted to chime in that a fix for this would be great. My use case is aligning fixed-width text with spaces, e.g.

• foo      bar
• longWord baz

[andersk]

According to the CommonMark spec "Line endings are treated like spaces", newlines are always valid to process. As for the whitespaces and tabs, it is hard to decide if we should process them given that browsers typically render them as single spaces, or should we respect the htmlWhitespaceSensitivity option in this case?

Whether or not newlines are significant to the output, replacing them with spaces can result in extremely long source lines that make editing unpleasant. I opened #11372 for this.

[Xunnamius]

Also experiencing this. Being a two year old issue, I'm kinda surprised I'm only just now encountering it. Use case: I'm trying to write documentation for GitHub and VSCode and don't want some inline code examples broken up across multiple lines.

What I typed:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis dignissim massa ex. requestPatcher: (req) => (req.url = '/myurl?some=query')

What prettier outputs:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis dignissim massa ex. requestPatcher: (req) => (req.url = '/myurl?some=query')

(view on desktop in a maximized window rather than mobile to see the difference)

[thorn0]

Fixed by #13590 in next