Can I control whether or not Obsidian is case-sensitive? This is not only creating issues when using the actual search function (which I understand can be toggled), but when I’m trying to link to one file from another, I have to either type it identically, case-wise, to the target link, or remember exactly what case I used for a title. Even when notes are aliased with all the variants, they still don’t always come up, which results in numerous unnecessary blank notes – and note content that weirdly ends up changed to a different case when these other notes have to be consolidated/renamed.
In my test vault I’ve got one file called Log. All of the following will link to that file:
[[Log]], [[log]], [[lOg]], [[LOG]]
I’ve also got two files called another and Another. They can be a little more finicky, but when I use [[ano it shows the file path in the auto completion list, so I can choose the “correct” one. If I don’t select one with a path, it’s kind of random which one it chooses.
So I’m not sure if that answers any of your concerns, but I’m using the autocompletion to select the “correct” version when I’ve got duplicated files in my vault. I’ve not experienced any issues so far, with referencing files, but your mileage may vary.
1 Like
I wonder if this is dependent on OS? holroy, are you on Windows, and a2jc4life are you on Mac/Linux by chance?
Except I tested on MacOS, and I can also link with no case-sensitivity, exactly like @holroy says.
@a2jc4life Also can you say a bit more about how you’re linking? Don’t you have auto-completion when creating a link? For example, another user was trying to type Markdown links []() instead of Wikilinks [[]], but they didn’t realize you can still use [[ to trigger auto-completion of a Markdown link. So they were typing links manually.
1 Like
I’m on macOs
I’m on Windows. I most often link by highlighting existing text and hitting [[ – which causes some problems because it doesn’t have all the same functionality as when you type a link from scratch. So I end up with… to use the same example, a file called Log. [[Log]] links to it. [[LOG]] and [[log]] each link to separate, empty files. [[Log|log]] will do what I want, but is both a hassle to set up, and not very intuitive.
Every time I link, say, notes I took from a book, instead of just linking the recurring keywords, I have to stop for every one and ask myself what I called that note, was it an alias or the actual note name, what case did I use, etc. – or I have to delete the text I want to link and retype it so I get auto-completion. That seems like a petty complaint, but it adds a lot to the overall workflow. And I understand when my text should be an alias to completely different wording – sometimes the limitations of the coding are the limitations of the coding – but case sensitivity should not be this hard to work around.
I don’t have this problem, but like the others I’m on Mac.
Do you see this behavior in the sandbox vault (found in the Help menu)?
Hmm. No. I can create a new note (manually) with the same name but different case, but linking existing text with a different case still knows to link to the original note.
(Just for testing, I linked the word “apps” from the main note. Clicking on that, of course turns that into a note. I then created a second note which contained “Apps,” highlighted it and turned it into a link…and it directs to the note “apps,” as expected.)
Curioser and curioser. It’s actually doing what I expect today across the board. I’m not sure why it didn’t seem to be showing the same behavior the other day.
Ohhh. Okay, I figured out, I think, why I thought it was not linking these properly the other day.
If you start to set it up like an alias because you aren’t sure which word is the title of the other note, it changes your case. e.g. right now I’m linking “church.” I couldn’t remember for sure if my main note is “Church” or “Churches,” so I inserted the bar and started typing to the left of it. When you do this, if you find the main note title and it’s different, it leaves your alias as you typed it in manually in the current note. If you find the main note title and it’s the same as your current alias, but the case is different, it changes your case.
So it changed my “church” to “Church.”
1 Like
So just making sure I read that correctly. Which part gets changed? The main link, or the alias? (Or both?)
Or are you saying, the main link gets changed, but the alias stays the same, so they can become inconsistent from each other. (I guess that makes sense because aliases should be manual, as far as I can imagine. Or no? I don’t use them very often.)
And then after these auto changes, are you able to recreate the problem where it links to a blank non-matching note?
In your opinion, do you think there is a bug or UX-improvement-feature-request here that should get reported?
Sorry; that was ambiguous. The text that I was linking gets changed to be consistent with the case of the actual target link title, instead of being treated as though it were an alias.
I don’t think it’s a bug, because it’s consistent with how true aliases are treated. But it’s a little confusing because it creates some inconsistency in how the same text-and-link combination is treated, depending on how you approach it. It might be helpful to clarify the behavior in documentation, so it doesn’t catch people by surprise, but I don’t think there’s a logical way to “fix” it.
1 Like
As a feature request, though, the search should be case-insensitive by default, IMO. It makes more sense to have to toggle case-sensitivity on than off for searching.
It is case-insensitive by default.
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.