fix issue #30, take care of uppercase

[chenyukang]

No description provided.

[chenyukang]

I'm not sure about why we use this function to compare:

/**
 * This function uses case-sensitive logic if a second argument has an upper case. Otherwise, uses case-insensitive logic.
 */
export function caseIncludes(one: string, other: string): boolean {
  const lowerOther = other.toLowerCase();
  return lowerOther === other
    ? one.toLowerCase().includes(lowerOther)
    : one.includes(other);
}

I think it will get some confused results, for example in demo gif:

When we input a word in lowercase, some capitalized candidate will come out, that's usually not we wanted.

A consistent behavior is, when we input capitalized prefix, candidates should be all in capitalized, when we input lowercase prefix, candidates should be in lowercase prefix. Make candidate list short and accurate will help on speed up input.

Maybe others may have different preference on this, so adding an option is also helpful.

[chenyukang]

I remove this to L27, because I think it will cost more time when words list in very long, in my case, 2w words 😂

[tadashi-aikawa]

As you said, it looks more faster, thanks 👍

[chenyukang]

A similar improvement can be done at https://github.com/tadashi-aikawa/obsidian-various-complements-plugin/blob/main/src/ui/AutoCompleteSuggest.ts#L41.

This will iterate the words again.
A better ways is just use a list, and iterate the word list one time, put valid candidate to the list.

[tadashi-aikawa]

This will iterate the words again.

What does that mean? 🤔

[chenyukang]

After you merge the code, the code line number is not right now.
It's now https://github.com/tadashi-aikawa/obsidian-various-complements-plugin/blob/main/src/ui/AutoCompleteSuggest.ts#L49.

we may remove this line for performance, because it will iterate the long list again.

.filter((x) => x.value !== undefined)

[tadashi-aikawa]

Thank you for your reply :) I understood.

On the other hand, It might be slow in the 10000case instead of 10000000case.

So I prior to readability for now.

[chenyukang]

In my local, I actually change caseIncludes to this:

export function caseIncludes(one: string, other: string): boolean {
    return one.startsWith(other);
}

This will complete in strict prefix.
Otherwise, we may have such kind of scenario:
I input a prefix some', candidate list contains 'handsome', I only want words starting with some` ...

Any special reason we use includes instead of startwith?

[tadashi-aikawa]

I'm not sure about why we use this function to compare:

Because I am inspired by Vim search mode. Vim search works as the caseIncludes function.

On the other hand, This plugin is for complements, not search. There are many different complements logics, but famous editors and IDEs suggest first what we input. (ex: a -> [aaa, AAA], A -> [AAA, aaa])

However, Obsidian is not IDE for a coder. Therefore, I think it would be suitable as you said.

Maybe others may have different preference on this, so adding an option is also helpful.

I agree. It is a bit of another issue, so I might implement it after merging your PR.

[tadashi-aikawa]

Any special reason we use includes instead of startwith?

I had thought it depended on how we use it or who uses it.

However, now I think they might be noisy in most cases. So I'll try it soon, thanks! :)

※ If no one uses partial match, it seems possible to complement more fast by indexing optimized. (in exchange for indexing speed)

[tadashi-aikawa]

By the way, this issue includes breaking changes as I didn't expected. So I'll merge it and then release v3.0.0 :)

[chenyukang]

I'm not sure about why we use this function to compare:

Because I am inspired by Vim search mode. Vim search works as the caseIncludes function.

On the other hand, This plugin is for complements, not search. There are many different complements logics, but famous editors and IDEs suggest first what we input. (ex: a -> [aaa, AAA], A -> [AAA, aaa])

However, Obsidian is not IDE for a coder. Therefore, I think it would be suitable as you said.

Maybe others may have different preference on this, so adding an option is also helpful.

I agree. It is a bit of another issue, so I might implement it after merging your PR.

Yes, if we want to execute a command line, fuzzy search is fine. Like VSCode, it also use 'includes' to match:

If we use to typing text, strict prefix matching will be better.

[tadashi-aikawa]

As an exception, It would be better for Internal Link Search to use insensitive-match. (at least in my case..)

[chenyukang]

As an exception, It would be better for Internal Link Search to use insensitive-match. (at least in my case..)

Yes, in this scenario it may useful. But I think we can control it only do fuzzy match if word is internal link, starts with [[.