Hello,

After having generated quite a few AsciiDoc files from Pandoc, an annoying bug kept coming back in my output: single enclosing characters are in many cases not enough to ensure an inline element is correctly parsed.

But in all those cases, it was a pretty easy fix: duplicating these enclosing characters fixed the rendering.

As far as I understand, the only case with which single enclosing characters is interesting to have as a feature is when the text is physically typed by a human: you only have to press once. Also, it is often the case that the text is being written with a rich-text editor, or live previewed. In these cases, the human directly notices that the formatting is not right.

Though, I do not see why Pandoc's AsciiDoc writer should bother with this fragile syntax, as the output is generated. It seems it might also have been your reasoning @jgm when you did 01b5459, for example. On a sidenote, know that @ggrossetie already implemented an AsciiDoc writer in TypeScript using this solution, maybe he will have some thoughts to add on this.

For example, if we take this Pandoc-flavored Markdown text:

This is a _test_[^1].

And yet another **one**[^1].

We can also try to write #hashtags [this]{.test}.

[^1]: Test footnote.

This AsciiDoc output is produced:

This is a _test_footnote:[Test footnote.].

And yet another *one*footnote:[Test footnote.].

We can also try to write #hashtags [.test]#this#.

Which is rendered by Asciidoctor like this (the screenshot is for readability):

But if we double the enclosing tags, such as this:

This is a __test__footnote:[Test footnote.].

And yet another **one**footnote:[Test footnote.].

We can also try to write #hashtags [.test]##this##.

We get the expected result:

I suspect those examples (which I genuinely stumbled upon) are not the only ones that can be solved by this approach, as this is not the first issue related to this matter (#1441).

If this approach is deemed relevant, I could maybe spend some time trying to work on a PR to try to fix it.