When searching for commands with telescope, the search stops after the search query has been repeatedly updated. It often stops after the first word, but this is not always the case. Sometimes it also works for multiple words.
These issues do not occur when using tag or notebook mode in telescope.
See for yourself:
Hi @Lukas,
thanks for the feedback.
I borrowed the fuzzy matching algorithm from CodeMirror, but it randomly works incorrectly on Telescope for some reason. Maybe it is by design for autocomplete?
Maybe I’ll consider switching it to another library.
I was quite surprised that this problem mainly occurs with commands. I have never experienced this problem with notebooks or tags, so it does not seem to be a general issue. I thought it might have something to do with the size of the list of items?
I tried some different queries and it seems that spaces are problematic, at least for commands.
What I don’t understand is why this isn’t a problem for notebooks and tags. I have created notebooks with names that match some command names (including spaces), and they worked as expected.
Haha, yeah, that’s interesting.
If you’d like to investigate further, check out the original FuzzyMatcher implementation here:
Surprisingly, it is just 150 lines of code (!)
Maybe you will find a hint 
I played a bit with the FuzzyMatcher implementation, but it seems to work alright. I tested the inputs from my first post against all Inkdrop commands using the matcher in a simple script, and it seems to work as expected.
The commands variable in the following is just the result of inkdrop.commands.findCommands({target: document.body})
function bestMatches(
query: string,
candidates: string[]
): Array<{ name: string; score: number }> {
const m = new FuzzyMatcher(query);
const res: Array<{ name: string; score: number }> = [];
for (const name of candidates) {
const r = m.match(name);
if (r) res.push({ name, score: r.score });
}
return res.sort((a, b) => b.score - a.score);
}
describe("FuzzyMatcher", () => {
it("core cut", () => {
const results = bestMatches(
"core cut",
commands.map((c: { displayName: any }) => c.displayName)
);
expect(results[0].name).toBe("Core: Cut");
console.log(results);
});
it("from selection", () => {
const results = bestMatches(
"from selection",
commands.map((c: { displayName: any }) => c.displayName)
);
expect(results[0].name).toBe("Core: New Note From Selection");
console.log(results);
});
});
I get the following as output:
stdout | test/fuzzyMatcher.commands.test.ts > FuzzyMatcher > core cut
[
{ name: 'Core: Cut', score: -1309 },
{ name: 'Core: Focus Next', score: -1316 },
{ name: 'Core: Focus Note List Bar', score: -1325 },
{ name: 'Core: Reload Package Updates', score: -1328 }
]
stdout | test/fuzzyMatcher.commands.test.ts > FuzzyMatcher > from selection
[ { name: 'Core: New Note From Selection', score: -929 } ]
This seems correct to me.
Hey @Lukas,
Thanks for looking into this! I tested it as well:
const m = new FuzzyMatcher('core cut')
m.match('core:cut')
// -> null
const m = new FuzzyMatcher('core cut')
m.match('core: cut')
// -> Matches!
Telescope tries to match option.label instead of option.displayLabel.
I think it could be fixed by replacing special chars like so:
private normalizeString(str: string): string {
// Replace common separators with spaces and collapse multiple spaces
return (
str
.replace(/[:_\-./\\]+/g, ' ')
// .replace(/\s+/g, ' ')
.trim()
)
}
result:
wdyt?
Wouldn’t this mean that you could never know what to search for? This could also be a problem for the highlighting, since the string the query is matched against is not the same as the one shown in the results.
I think it would be best to just use the displayLabel property to match against. But maybe I’m missing something.
Just as it comes to mind: Maybe it would also be useful if a command could set its own display name instead of automatically generating one from the command. For example, “Cut” would probably be enough to describe it. The “Core:” part is not really necessary.
Telescope can support various types of sources.
I followed the practice of CM6’s autocomplete implementation, which tries to match with label, while allowing custom displayLabels.
So, it has getMatch like CM6 so that an option can properly highlight for its displayLabel:
https://codemirror.net/docs/ref/#autocomplete.CompletionResult.getMatch
I don’t have a concrete use-case for this feature yet though, I would like to just follow CodeMirror’s way for now.
Ok i see where this is coming from. In this case it looks good to me.
Fixed in Inkdrop Desktop v6.0.0-canary.3!
but I’ll be revisiting this later again
