Issue with "Alias" Property Parsing Uppercase vs Lowercase Variations of Same Word

Questions & Help
1

I am new to Logseq and I am trying to use the alias page property to distinguish between uppercase and lowercase variations of a page name. So, for instance, if I create a page entitled “Mind”, I would like to use the alias page property to include the lowercase spelling “mind” as well so that the link [[mind]] points to the page “Mind”.

I have been unsuccessful in my efforts to get this to work as Logseq seems to only recognize [[Mind]] (and not [[mind]]) as a valid link to the page “Mind”. Although seemingly a minor point, it is rather frustrating because it can have a meaningful impact on the readability of my notes.

Am I missing something here or is this just a limitation of the way Logseq works?

1 Like
2

I don’t think it’s necessary to use aliases to distinguish variations of a page name, Logseq should link to the page either way. However, when trying this out, I was surprised by some of the resulting behavior:

  1. If I have a page named test I could write any of the variations [[test]], [[Test]], [[tEst]], [[TeSt]], etc., and they would all link to test and be displayed with uppercase and lowercase letters just as written.
  2. However, if i named the page Test instead, the variations [[test]], [[Test]], [[tEst]], [[TeSt]] still all worked, but [[test]] would display as [[Test]] when exiting edit mode.

It therefore seems like having lowercase page names gives more flexibility in how links to the page are displayed, but maybe it’s possible to change this behavior somehow? Maybe this is well known, but I hadn’t realized until now. Personally I like having uppercase page names, but will have to be more conscious of this if it affects how links are displayed.

Btw: To make links using variations of page names you can also write e.g. [testing]([[test]]).

1 Like
3

Yes, I had noticed this in Respect lowercase page link, when page title is capitalized. Please vote for the feature request (which might be as well a bug).

Logseq should not limit us in any way here. I also like to user upper case, which is very common in Wikipedia style.

1 Like
4

My approach to this is the following:

  1. Name pages lowercase by default
  2. Use uppercase for page names only with proper names, for example [[Alice]]
  3. Reference pages with [[name]] or [[Name]] depending on the context.

The issue is that I need to remember not to type [[Name]] for a yet not existing page because it would be created with uppercase.

2 Likes
5

Logseq is sort of case-insensitive so yes Mind and mind in the backend is the same.
Each page in the backend has an attribute :block/name which is always the lowercase name of a page.
There is also :block/original-name which is the original case use.
I would say this explains (part of) the observed behavior.
So it doesn’t make sense to use alias to define a different type of case. In the backend that would still be the exact same page.

3 Likes
6

My thanks to everyone who has replied to my original comment and for all your suggestions.

I agree with @sandfish that when it comes to structuring data, Logseq should give the user as much freedom, with as little friction, as possible. As such, I should not have to worry about whether I am creating a page with an uppercase vs lowercase name.

All the same, I thank that going forward I am going to do what @alex0 suggested and default to using lowercase page names (excep for proper nouns).

Finally, my thanks to @hghugdal for the clear and succinct description of the problem and all the permutations of how it shows up. That description alone went a long way towards assuaging my anxiety with some of Logseq’s rougher edges.

1 Like
7

I switched all my pages to this format, just because of the visual (and perhaps more) inconsistency described in this thread (which I myself have also observed).