#6

I agree that this is something important and we should do it. I agree that we may even change the default behaviour to ignore diatrics. I don’t consider it a bug.

2 Likes
#7

I incorrectly filed a bug report about Different Unicode code points some weeks ago. Although it’s not Obsidian’s fault, and given the variety of reasons that may lead to these inconsistencies creeping in, I’d prefer it if it were more permissive by matching characters with and without diacritics.

2 Likes
#8

Relatedly, I think it makes sense for the fuzzy search in the link suggestions to ignore diacritics.

#9

+1
For those who mostly use non-English languages, this is an essential feature.

4 Likes
#10

We need this.

#11

Yep, here’s a case where I wish the order in autocomplete was better:

Screen Shot 2021-04-22 at 8.49.17 AM

1 Like
#12

Any chance that this might be implemented soon (viz. the default becoming diacritics ignored)?

#13

Hi
In the search tool can I disable the sensitivity to this type of symbols that go over letters in some languages: ^¨~´` ?

I searched on help docs.

Thankyou

#14

+1 Would be great for Vietnamese users :blush:

#15

+1. Would help working with texts in Pali (language used in the Buddhist scriptures, like the Pāli Canon)

#16

+1 I need this desperately.

#17

This would be extremely useful for spanish speakers, not only for Search, but also for Quick Switcher and Internal Links :pray:

#18

Does anyone knows why despite this is so important for many non-english speaking users, is so difficult to accomplish / or ignored ?

#19

+1

Me and others non-English speakers would love this feature. I think that may be reasons to keep diacritics for some one. Why not include a switch bottom on settings with this option?

1 Like
#20

+1! I need this behaviour as well.

1 Like
#21

Use case: Searching for a note with “à” in its name, can’t use “a” in the query

If I have a note that uses special characters such as accents, Obsidian treats these as entirely different characters. This makes it hard to find such notes with the search function if you don’t know the precise spelling. For example:

If you have a note titled “ànima”, you can’t use the query “anima” to find it. This can become even more complex if there are multiple of such characters in the name.

Proposed solution

To have a toggle switch next to the search bar (maybe it can be en/disabled in preferences for those who do/n’t need it) that lets you treat special characters the same as their “base” version. So typing a in search would also match à, á, â, ä, æ, ã, å, ā, etc.

One simple way to get a partial list of such variations on macOS is to hold down the key and wait for the popup to show up with the possible variations. For example if you hold the a key for a second, a popup shows up with 8 alternate versions of it.

I suppose in the preferences there could be a list of all the characters that you want to associate with the base character. Because this problem can multiply in complexity as you add languages and character sets, making it user customisable might alleviate the implementation burden. So for a you’d have a text-field in which you can add other variations.

Current workaround (optional)

All I can think of now is to not use such characters in the filenames, but this is far from useful.

3 Likes
#22

Use case or problem

In spanish we use to have letters with accent as “gráfico”. So it happens that I can have a note that is called “Gráfico lineal”. But when I use quick switcher I would like to be able to search independently if the letter has the accent á or not. I think it can happen to other languages as well.

Proposed solution

Ignore the accents on the letters when searching with Quick Switcher.

1 Like
#23

The correct solution would be to implement a search in a fuzzy way. I was testing with vim+fzf and it works perfectly when searching for information, in fact I am surprised that obsidian does not use that type of search by default.
Here is a nodejs repository GitHub - wouter2203/fuzzy-search: Simple fuzzy search so creating a plugin or integrating it into obsidian shouldn’t be too complicated

2 Likes
#24

Piggybagging this for similar reasons, the search

“and concentration”

should find the same words in the following text:

its provenance, depending on the type of water use, and the type and concentration of the pollutants;

However, because markdown formatting is not escaped by the search, and the word “concentration” is bolded, one can only find this text passage when searching for the string

“and **concentration**”.

Which makes the search very problematic, because key-words are often formatted in some way.

To that end, formatting should be escaped in the search by default.
I suppose implementing a fuzzy search like giancarloaparicio suggested could have the same result.

I am generally always in favour of fuzzy searching as an option. Maybe even as default search, but at least an option.

To be honest, I am somewhat shocked that obsidian has such limited search capabilities out of the box, because it’s neither fuzzy, nor RegEx-capable out of the box. The latter is somewhat extendable via a plugin, but it requires a unique search box which

  • covers the main screen, instead of popping up at the bottom
  • cannot purely search, as it is build as a search&replace tool. If you want to do a regex-search, you always must replace for something
2 Likes
#25

+1 for this.

In a similar vein, it would be good if search was agnostic about normal and “smart” quotation marks. E.g. currently, if I search for “Administrator’s” (without smart quote) I will not find “Administrator’s” (with smart quote). This makes using the Smart Typography plugin a lot less useful.

1 Like