See [[plan]] for the steps.
Ask [[jane-doe-notes|Jane Doe]] before you merge.
``` Neither reader made an `` tag. Brackets, pipe and both names survived as ordinary characters, and both commands exited with code 0. A short bracket form does exist in the CommonMark spec. There, a shortcut reference link needs its label to match a reference definition found elsewhere in the same document (spec lines 7655-7658 of version 0.31.2). Since `wiki.md` defines no references, the inner `[plan]` had nothing to match. ## The wikilinks_title_after_pipe runs Both readers list this extension with a minus sign, so it has to be switched on by name. Adding a plus sign and the name to the reader turns it on for one run: ```sh pandoc -f markdown+wikilinks_title_after_pipe -t html wiki.md pandoc -f commonmark+wikilinks_title_after_pipe -t html wiki.md ``` Each command wrote these three lines: ```htmlSee plan for the steps.
Ask Jane Doe before you merge.
``` The left half, `jane-doe-notes`, went into the `href`. The right half, `Jane Doe`, became the visible text. With no pipe at all, `[[plan]]` used the one word for both jobs. Every tag also gained `class="wikilink"`, a marker missing from the plain runs. The HTML wraps before `merge.` even though the source sentence sits on one line. ## The wikilinks_title_before_pipe runs The second extension takes the same input. Only the name after the plus sign changed: ```sh pandoc -f markdown+wikilinks_title_before_pipe -t html wiki.md pandoc -f commonmark+wikilinks_title_before_pipe -t html wiki.md ``` Both readers returned this: ```htmlSee plan for the steps.
Ask jane-doe-notes before you merge.
``` Nothing in the input says which order its author had in mind. The pipe is the same character under both settings. Here the halves traded places. `Jane Doe` became the `href`, with its space kept, and `jane-doe-notes` turned into the text. The first paragraph matched the after-pipe output exactly, since a link with one word has nothing to swap. So a file typed for one order and read with the other gave a different address on the piped link in this test. The bare link came through fine, so the swap showed up in one link out of two. ## Turning on both pipe orders together The extra script named both extensions in one reader string, then again in reverse: ```sh pandoc -f markdown+wikilinks_title_after_pipe+wikilinks_title_before_pipe -t html wiki.md pandoc -f markdown+wikilinks_title_before_pipe+wikilinks_title_after_pipe -t html wiki.md ``` Pandoc took both strings without an error and exited with code 0 each time. The two runs gave the same HTML: ```htmlSee plan for the steps.
Ask Jane Doe before you merge.
``` That's the after-pipe result, line for line. Whichever name came first, the after-pipe reading won in this test. Naming one extension per run keeps the outcome plain to see. ## A space, a hash part and nearby emphasis The extra script brought in `wiki-target.md`, whose targets hold spaces and a `#` part. Here is `cat wiki-target.md`: ```text Read [[project plan#Steps|the steps]] first. Then open [[Doe Holdings notes]]. ``` It ran with the after-pipe extension: ```sh pandoc -f markdown+wikilinks_title_after_pipe -t html wiki-target.md ``` ```htmlRead the steps first.
Then open Doe Holdings notes.
``` The `href` kept `project plan#Steps` exactly as typed. Pandoc added no percent codes and did not split off the part after the hash. The three-word target also kept its spaces, and the wrap fell inside the link text. A second new file, `wiki-mixed.md`, puts the links among other inline Markdown and adds a code span: ```text **Before** you merge, read [[plan]] and *then* ask [[jane-doe-notes|Jane Doe]]. Typed as code, `[[plan]]` stays as text. ``` It went through both readers with the after-pipe extension: ```sh pandoc -f markdown+wikilinks_title_after_pipe -t html wiki-mixed.md pandoc -f commonmark+wikilinks_title_after_pipe -t html wiki-mixed.md ``` The two commands gave the same HTML: ```htmlBefore you merge, read plan and then ask Jane Doe.
Typed as code, [[plan]] stays as text.
` element. A code span kept the brackets visible here even with the extension on.
## What the extension lists say
Typing `pandoc --list-extensions=commonmark` prints one extension per line, a plus sign for on and a minus sign for off. The `markdown` list works the same way. Both readers carry the two wikilinks names switched off:
```text
-wikilinks_title_after_pipe
-wikilinks_title_before_pipe
```
In the saved lists those entries sit at lines 71-72 for `markdown` and lines 28-29 for `commonmark`. A fresh listing in the extra script, filtered for the word wikilinks, printed the same pair for each reader.
A misspelled extension name doesn't pass silently. A control run asked for `+no_such_ext`, and pandoc stopped with `The extension no_such_ext is not supported for markdown.` and exit code 23.
The sibling test on [a Markdown table without a header](markdown-table-without-header.md) reads these same two lists for its table extensions.
## Steps for checking wikilinks in a file
The extra script ran each command below on `wiki.md`. Wherever `wiki.md` appears, use your file's name.
1. Count lines with double brackets: `grep -c '\[\[' wiki.md`. It printed `2`.
2. Convert with the after-pipe extension: `pandoc -f markdown+wikilinks_title_after_pipe -t html wiki.md -o wiki-after.html`.
3. Count the tags pandoc built: `grep -c 'class="wikilink"' wiki-after.html`. It printed `2`, the same as step 1.
4. List each address with its line number: `grep -n 'href=' wiki-after.html`. Line 1 held `href="plan"` and line 2 held `href="jane-doe-notes"`. If an address shows the display words, switch to `wikilinks_title_before_pipe` and redo step 2.
5. Run a control with no extension: `pandoc -f markdown -t html wiki.md -o wiki-plain.html`, then `grep -c 'class="wikilink"' wiki-plain.html`. This time grep counted `0` and returned exit code 1.
## Where Sashmark fits
Sashmark's opening release is intended to let you edit text in the same view you read it in. With the Round-Trip it targets, saving could keep all other bytes of that file as they stood. Changes View, part of that same release plan, could highlight what an agent edited since your most recent pass, with or without git.
It is in development and has not been released. The app itself has no AI features. See the [planned features](/features), the [help pages](/help) and the [roadmap](/roadmap) for where each part stands.
More at [sashmark.com](https://www.sashmark.com/).