Enhancement of aliases

Currently there are quite a few issues regarding aliases:

To me, these bugs seems similar. The aliases are not powerful enough to be completely replaceable with each other. However, they are neither “simple and stupid”[^1], so there are not “source of truth” and confusion arises.

[^1]: e.g., Obsidian recommends

Rather than just using the alias as the link destination ([[AI]] ), Obsidian uses the [[Artificial Intelligence|AI]] link format to ensure interoperability with other applications using the Wikilink format.

When it comes to hierarchy, things become especially confusing. Maybe the data model is just incompatible in this case? TBH I couldn’t imagine a non-trivial solution to make them work well together :frowning:


BTW, I guess some people would view them as “bugs” instead of “feature request” (especially for the tag/query issue for pages without hierarchy). But as @Bad3r commented here, I just create a feature request here to help aggregate votes and discussions.

So currently my rule of thumb is just to avoid using aliases (as page links) if you want to use queries or hierarchies.

I’ve heard that the implementation of aliases is a bit flimsy.

I tend to avoid aliases and use [Alias]([[Page]]) syntax. It seems it works a bit better.

2 Likes

That’s a good workaround (which I didn’t even think of), similar to Obsidian’s [Page|Alias]. It will also be acceptable to me if Logseq can automatically switch to that representation when link to alias is selected.

I suppose in the long term they will rewrite the implementation of aliases but at the moment they have other priorities.

I agree, I stopped using aliases for the most part when I ran into multiple issues with them.
Even [alias]([[page]]) is not flawless as these links show up in both linked and unlinked references for some reason.

The inline alias (including obsidian’s implementation) has one problem:
I believe one purpose of logseq’s alias is to avoid fragmentation when you can’t remember which name you gave the page that you want to link to. If I can only think of the wrong keyword, [[]] autocomplete won’t help and I’ll end up creating a duplicate page with information fragmented between them. Inline alias won’t help this case.

1 Like

So my suggestion is:
Redefine “alias” as a list of comma-separated values (that do not contain [[]]) to add alternative names to the search index without creating actual pages or relations in the graph. If [[A]] has alias “B”, after I type [[B]] I can select “B (alias of A)” in the autocomplete pop-up, and the result is automatically changed to [B]([[A]]) (or the org equivoque [[A][B]]).

Because no additional page is created, hopefully this will solve the namespace problems and other bugs.

To me it is the perfect implementation if it exists in a vacuum. But to think how to maintain backwards compatibility… I have a headache.

3 Likes

I think “unlinked references” have many bugs that need to be reported :joy:
for example org-mode tags :tag1:tag2: also show up in both.

There is no need to introduce any change to UI/UX. The way aliases should work is clear but the current implementation is just a patch and not a proper one.

1 Like