I don’t know if this is the right place to put this, but to put it in “Feature Requests” is pointless, because it is very unlikely to be implemented, so it will just be immediately moved to the Feature Archive. Still, I think this is worthy of discussion.
The way piping works in Obsidian is backwards. It is counter-intuitive and hard to read.
The way normal Markdown links work is [text](link). That makes sense, and is relatively easy to read. The text is the important part; the link is just there for reference. Therefore, the text comes first.
However, internal links work exacty backwards from this. They go [[link|text]]. This is problematic for two reasons. First, it’s reversed from the way Markdown links work, so it’s very difficult to remember (I get it wrong every single time unless I use the Better Link Inserter plugin). Second, it’s extremely confusing to read as Markdown. The text comes last, so reading it normally is difficult to impossible. Here are two links I used recently, in context, to demonstrate the problem:
[[Matter/A Libertarian View of Gay Marriage#^ChestertonsFence|Chesterton’s Fence]] is a concept I came up with long before I heard the term (not using his metaphor, of course), although Chesterton frames it far better than I could have.
This is a lot bigger than what I’m dealing with here, and I’ve discussed some of that [[Chesterton’s Fence and the Burden of Justification|elsewhere]].
These are, I hope you’ll agree, essentially unreadable. You can’t start reading it and then ignore everything after the pipe; you’ve got to do the opposite: Read something that makes no sense, then when you reach the pipe, discard what you’ve just read in your mind and replace it with what comes after the pipe. This is not how minds work, so it ends up being challenging and confusing. Imagine reading an article with several of these in it!
One possible reponse to this is, “just use Live Preview or Reading view! Why are you in Source mode at all?” But that seems to me to be an argument against using Markdown in the first place. If our files are unreadable in plain text, why not just use HTML, or another portable format, like RTF?
Now, as I said above, I realize that this is unlikely to change, at least in the near-term. There are two reasons for this. First is the reason, I presume, it was set up this way in the first place: Doing it the other way messes up the [[ autocomplete functionality. You’d type [[, start entering your text, it would try to autocomplete stuff you don’t want, then you’d enter the pipe and then not have the benefit of autocomplete. Second, people already have a bunch of links formatted in the current way, and reversing it would break all of those.
However, it seems that both of these problems are resolvable. For the first, just implement something along the lines of what Better Link Inserter does: Enable selecting a word and then using a hotkey or button to create a piped link, which then pops up autocomplete options. And/or create a feature so that when you typed [[| it would pop the insertion point back before the pipe, disable autocomplete, and then when you typed | again (or right-arrowed), autocomplete would work again. Or something else; I don’t want to specify the exact UI here; getting it right would require thought and testing. But I’m reasonably sure it could be done with minimal fuss and no change at all for anyone not using piping.
For the second, this is even easier: When the feature changes, just have Obsidian go through all your notes and flip all the piped links for you. It could even be something you’d have to manually choose to do: When you enable the new “flipped” piped links feature, it would then flip all your links. Apple does this sometimes, when it implements a new feature that might cause compatibility issues.
An amusing side note: The Obsidian Help on this topic doesn’t specify which way piping works! You’ve just got to figure it out for yourself. Is this an indication that the devs are still up in the air as to the right way to do this?
The point of all of this is to try to generate a consensus of the “right” way to do this, so that at some point in the future (maybe in 2.0) that functionality could be introduced, instead of making a feature request that would be immediately archived and subsequently forgotten about.