Two hypens are rendered as dash in inline content #1717
In shell commands "--" is often used to separate parameters and arguments. Unfortunately two hyphens are not always correctly rendered in inline content.
Given an input file with the following threee line
With Asciidoctor 1.5.1 the two hyphens in the first example are rendered as dash. In all other examples the two hyphens are rendered correctly.
The text was updated successfully, but these errors were encountered:
According to http://asciidoctor.org/docs/user-manual/#replacements
This for inline content; if you wanted the command on a line by itself (ie a block) start the line with a space - then you don't need the pass macro or the backticks.
git checkout -- .
In certain cases. It depends on the neighboring characters.
It's important to remember that, as of Asciidoctor 1.5, backticks are for producing normal text in a monospace font. Normal substitution rules apply (just like if you made the text bold). In other words, the content is not treated literally.
To prevent the substitutions from occurring, you need to use one of the following:
The most common approach is the
See http://asciidoctor.org/docs/migration/#migration-cheatsheet for details.
The reason we made this change in Asciidoctor is two-fold:
In the future, we may be able to limit the substitutions that occur within monospace text more intelligently, since hyphens are rarely desired there. However, we can't do it with the current inline parsing technique we're using.
The annoying part is that you have to pay attention to when substitutions are being applied if you want to use
Yes. That's because +++ means to skip substitutions both for the input and the output. In other words, copy the content directly to the output stream.
While it doesn't matter in this example, if the command contained a
By default, the inline pass macro and +++ do the same thing, but the inline pass macro supports a custom substitution list. I updated the example above so that it encodes special characters (
It's not a perfect solution, so let's soften this to say "in most cases".
"In most cases, replacements (table, section 40.4) can be escaped by adding a leading \ character (e.g.,
Let's drop this one. It's too vague.
Yes! Very good.