Exclamation marks before square brackets get lost

[marcelotto]

When parsing an Obsidian-flavoured Markdown document containing an embedded document, like ![[Foo]], the produced AST omits the exclamation mark. Consequently, when regenerating the Markdown document from the AST, the exclamation mark is lost.

An additional problem is that the square brackets are escaped during the AST roundtrip, which does not happen when one of the new wikilinks_title extensions is enabled. With the exclamation mark in front, however, the double square brackets are no longer detected as links (besides losing the exclamation mark).

I'm aware of the existing issue #553 discussing transclusion support. However, my concern here is not about adding transclusion support but ensuring that no information gets lost during the AST generation and regeneration process.

Steps to Reproduce

1. Create a Markdown document example.md with the following content:

   ![[Foo]]

2. Parse the document to produce an AST using Pandoc: pandoc -f markdown+wikilinks_title_after_pipe -t json example.md > example.json
   This produces:

    {
      "pandoc-api-version": [
        1,
        23
      ],
      "meta": {},
      "blocks": [
        {
          "t": "Para",
          "c": [
            {
              "t": "Str",
              "c": "[[Foo]]"
            }
          ]
        }
      ]
    }

3. Regenerate the Markdown document from the AST: pandoc -t markdown+wikilinks_title_after_pipe example.json

Expected Behavior

The regenerated Markdown document should retain the original embedded document syntax, including the exclamation mark:

![[Foo]]

Actual Behavior

The exclamation mark is missing in the regenerated Markdown document and the brackets are escaped:

\[\[Foo\]\]

Additional Information

• I've noticed the same behavior also for exclamation marks before single square brackets (although I don't care for this in my use case).

Pandoc version

$ pandoc -v
pandoc 3.0.1
Features: +server +lua
Scripting engine: Lua 5.4

on MacOS 13.5.

[jgm]

Actually the same issue appears with

![foo]

The problem is that makeFallback in referenceLink doesn't take account of the fact that referenceLink might be called from image.