Backslashes in code spans seem to escape themselves

[mgeisler]

Problem

This issue was noticed when I was writing about Rust raw strings.

I had to write

`r"\n" == "\\\\n"`

to get

<code>r"\n" == "\\n"</code>

in the HTML. This is strange, since code spans disable all escaping: Example 17 and Example 338.

Steps

% mdbook init --ignore none --force backticks
What title would you like to give the book? 
test
2023-04-27 20:03:30 [INFO] (mdbook::book::init): Creating a new book with stub content

All done, no errors...
% cd backticks
% echo $'foo `x \ x` bar `y \\ y` baz' > src/chapter_1.md
% mdbook build
2023-04-27 20:04:12 [INFO] (mdbook::book): Book building has started
2023-04-27 20:04:12 [INFO] (mdbook::book): Running the html backend
% rg 'foo.*bar.*baz' book/chapter_1.html
147:                        <p>foo <code>x  x</code> bar <code>y \ y</code> baz</p>

In this example, the lone \ has disappeared, and the \\ was turned into \.

Possible Solution(s)

No response

Notes

I tested pulldown-cmark briefly with a small program that shows the events it emits. It seems to do things correctly:

Input:
`r"\n" == "\\n"`

Events:
Start(Paragraph)
  Code(Borrowed("r\"\\n\" == \"\\\\n\""))
End(Paragraph)

The Borrowed variant shows the Rust-escaped string, and it has a \ and \\ as expected.

My guess is that something un-escapes the generated HTML before saving it to disk.

Version

mdbook v0.4.28

[ehuss]

Can you verify in your reproduction that you have this in chapter_1.md:

foo `x \ x` bar `y \\ y` baz

The particular echo statement you show behaves differently based on the shell used.

With those contents, I see the expected:

148:<p>foo <code>x \ x</code> bar <code>y \\ y</code> baz</p>

[mgeisler]

The particular echo statement you show behaves differently based on the shell used.

Right, silly me, I should have checked that :facepalm: Thanks for reminding me!

I am not able to reproduce it in a fresh book... I suppose the problem is somewhere in the configuration of my real book. I'll keep digging — it just occurred to me that the problem could be the way we process the speaker notes with a bunch of JavaScript.

[mgeisler]

I haven't seen this since so let me close this again.