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.
Some previous failed engineering attempt: Enhance: Add alias support to page-ref [WIP] Close #7183 by andrewzhurov · Pull Request #7248 · logseq/logseq · GitHub
GitHub tickets for centralizing the requests:
opened 05:15AM - 24 Mar 22 UTC
:type/enhancement
graph
search
ux
page-ref
### What happened?
I found the alias feature works in an unusual way, and aft… er checking this issue https://github.com/logseq/logseq/issues/4342#issuecomment-1048049248 and the related discussion, I figured it out and think it's really nice.
> this is actually a feature, not a bug :
> * if [[aliaspage]] is empty, all links are redirected to [[sourcepage]]
> * if [[aliaspage]] has a different content from [[sourcepage]],links are displayed as linked refs in the sourcepage
>
> you can read more about the implementation and arguments in this topic: [discuss.logseq.com/t/improve-implementation-of-aliases/81/8](https://discuss.logseq.com/t/improve-implementation-of-aliases/81/8)
BUT, here is what I cannot figure out:
- If there no content/page for some alias which means they're **identical** to the "source" and not in a link-and-backlink connection, why link all the alias to each other in the graph? And it makes no sense to link all the backlinks to them separately. This causes tons of duplications in the graph view and create a huge obstacle to figure out the real relationship among them.
- Same for the searching result.
Instead, you could only show the source node, and list all its alias beneath it. It will make the result way much clearer and may also alleviate the potential performance issues.
I list some of my rough thoughts in the following. Please consider improving current graph view experience. Thank you.
### Reproduce the Bug
Just preview a page with a couple of alias.
### Expected Behavior
_No response_
### Screenshots
- For a set of alias nodes:
- `test1` is the source file
- `test2` and `test3` is alias to `test1` and has no content.
- `testing` is alias to `test1` but has different content.
- `foo1` is linked to source file `test1`
- `foo2` is linked to alias `test2`
- `foo3` is linked to alias `testing`
- A possible alternative for the graph view:
<img width="1363" alt="solution" src="https://user-images.githubusercontent.com/25447610/159845456-aabfdeef-8eea-4c9d-9bc6-5df27c2accd7.png">
- Possible alternative for the search result:
<img width="909" alt="Xnip2022-03-24_12-57-44" src="https://user-images.githubusercontent.com/25447610/159845488-c7ad2ec6-5f65-44dc-90ef-4f36a887bc34.png">
### Desktop Platform Information
- MacOS 10.15.7
- logseq 0.6.4
### Mobile Platform Information
_No response_
### Additional Context
_No response_
opened 07:31AM - 05 Feb 22 UTC
query
:type/feature-request
hierarchy
props:alias
estimate: large
### What happened?
Alias is not support for hierachy in title;
version: 0.5.9
…
### Reproduce the Bug
1. build a page «**[[Parent/Child]]**»
2. Open »**[[Parent]]**» page, add alias "Father" by method in document [E](https://docs.logseq.com/#/page/term%2Fproperties)
Result: Cannot use »**[[Father/Child]]**» to taget page
### Expected Behavior
Expect: »**[[Parent/Child]]**» should be the same as »[[Father/Child]]»
### Screenshots
_No response_
### Desktop Platform Information
- OS: win10
- Version: 0.5.9
### Mobile Platform Information
_No response_
### Additional Context
_No response_