`Shift + |` Does not Autocomplete Wikilink Suggestion like `#` or `^`

Steps to reproduce

Searching for note [[Test]]

  1. Open wikilink suggestor [[Te]]
  2. Suggestor shows Test
  3. Press shift + | (pipe)
  4. See Wikilink completed as [[Te|]]

Did you follow the troubleshooting guide? Y

Expected result

[[Test|]]

Similar to how shift + # and shift + ^ function, I expect shift + | to fill in the autocomplete and allow me to enter display text.

I am aware tab then pipe nets me the result I’m after, but this goes against the standardisation of the other two approaches. Seeking feedback.

Actual result

[[Te|]]

Environment

SYSTEM INFO:
Obsidian version: v1.6.5
Installer version: v1.6.3
Operating system: Darwin Kernel Version 23.5.0: Wed May 1 20:14:38 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6020 23.5.0
Login status: not logged in
Insider build toggle: off
Live preview: on
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: off
Plugins installed: 5
Plugins enabled: 0


Additional information

First hash, second caret, third pipe.

Jul-24-2024 21-22-10

Not a bug. This is how it intended to work.

What is the reasoning?

This was asked a few times. Try to search the forum.

This explains it better:

Still doesn’t make sense to me, aliases and display names are different things. Just seems odd there is different functionality between seemingly the same things (hash, caret, and pipe).

My brain really doesn’t compute this. Could be an option? I never write a wikilink for a page that isn’t created, so I truly can’t grasp the concept or reasoning here.

Feel free to search/open a feature request for this.

Based on the logic you’ve provided, why then does # autocomplete? It does not require a note or section to exist—so I truly don’t understand how this cannot be conceived of as a bug. Same for caret, why does that autocomplete at all then, if the page doesn’t have to exist? It’s not like I update a caret link and it’s updated around the entire vault, I get errors saying “cannot find this section”.

This isn’t help, this is a UX issue and a bug. One approach for one thing, and another within the same box is poor.