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
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 @Bader commented here, I just create a feature request here to help aggregate votes and discussions.
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 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.
So my suggestion is:
Redefine “alias” as a list of values that do not contain [[]] (comma-separated or each enclosed in quotes) 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 equivalent [[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.
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.
Separate issue speaking of enhancement of aliases: languages with inflections.
It’s non-issue in English, but in some languages (Spanish, Russian and so on) there are inflections on words, i.e.: Школа, Школы, Школе, Школой — it’s all the same word “School” which transforms, depending on sentence structure.
Writing in this languages it get’s very cumbersome to link pages, since every word has several variations.
One of the easier solutions I can see - is to allow regex or even something simpler in aliases.
Suppose I could’ve write alias:: школ*, meaning any word that starts with “школ”
I guess there will be a problem, when I manually type in (w/o autocomplete) [[B]]. What should happen when I click that link? Creating new page «B» or jumping to page «A»?
ooh great question. If the user ignores the pop-up, I think it’s better to create a placeholder page for [[B]], and as no actual file is created until there is content, this placeholder page could show Click here to merge with [[A]] which already has an alias of the same name in front of the usual Click here to edit.... Then it’s up to the user whether they want to merge, or really just have B as a separate page as weird as that is – if the latter, when the user types [[B]] again, the autosuggestion would have 2 options: B (just the page) and the alias one (so the search index needs to store whether an entry is an actual page or an alias in order to allow both to exist). (Edit: It also allows multiple pages to have the same alias, which users might do consciously or accidentally, which is nice.)
A problem though: while hovering a link to view it in “tooltip”, it automatically creates an empty bullet in it if it’s originally an empty nonexistent page. I don’t know if this is a bug or a feature.
With all that, I realize this is my wishful thinking such drastic change is not going to happen.
It can be done in a plugin for example sethyuan’s “smartsearch” and a different property name like or:: instead of the default alias, but it’s not very attractive because typing [[ for the autosuggestion is already muscle memory
User nickmartin117 on Reddit shared a custom.js script to give you abbreviated namespaces. So instead of [[work/meeting/project 1]] you would get [[w/m/project 1]] which is much more compact.
Code is here: https://gist.githubusercontent.com/Zyrohex/9782b737f8f7f7bca7b6cc7e7868d793/raw/980bfe98fffa8671350d89cf1ecf74637a9fc64a/custom.js
It looks like doing something "using namespace as "
Anyway, we need to centralize these tickets about adding alias support, as the routing system requires careful handling.
Also, as using text-based storage, alias is not that solid. Expanding the support would be hard and dangerous. We need to do that carefully, and in one shot.
For me aliases are “synonyms” - additional names for one page. It is common and widely used approach to have several names for one thing.
So, it is vety confusing that in Logseq aliases produce additional pages with potentially different content. It makes everything very complex.
If we want to have additional functionality with aliases, maybe it would be better create another mechanism for that? Don’t overload aliases with comlex functionality.
Two simple solutions is better than one but hard to use and hard to understand.
So, my proposal is: let aliases to be just synonyms of one page. And nothing more.
Hi there,
an interesting application is to assign the negation of a page name as alias to avoid page fragmentation.
I use Passwordless authentication as alias for Password authentication for example - both essentially form two sides of the same coin. This practice comes from Wikipedia (and I bet they spent a lot of time on knowledge organization).
It would be nice for this use case, if you could explicitly search for the aliased term. As of now Linked References don’t not show up aliases (feature request: have additional filters for the alias). Simple queries search for everything given either the original term of alias, which is fine as default (feature request: Provide a flag to only search for the alias). I think, advanced queries make this possible, but are often too cumbersome.
such drastic change is not going to happen.