BugsAlaz Oz·9 days ago
Done
"/" Commands menu search doesn't match mutiple words
There are multiple options in the commands menu which are multi-word (eg. "Heading 1", ...). Which don't show up when typing something like "/h1".
Expected behavior
When typing "/h1", it should show up multi-word matches. ("Heading 1")
6 Comments
Sign in to comment
AO
The current matcher matches text that are continuous.
The required implementation:
"/yt" should match ("youtube")
"/h1" should match ("Heading 1")
I'm not sure if this is the best idea overall, because there's a future where / commands are also used to directly add Collections as object blocks, such as /task /meeting /note or whatever. By putting so many matches across other commands, it may add more conflicts than the benefit it provides. Headings already have the markdown as # as the primary shortcut. I'm curious if other testers see this as necessary.
Another way would be to add alias for searching certain things, like h1 for heading 1, yt for youtube.
Or the matcher could be an option under preference.
Heading 1 is already #. It's effectively faster to use markdown for all of those heading shortcuts.
For yt, I can see the point. But it'd be better implemented by simply auto creating an embed/block/bookmark based on what is pasted from the clipboard.
We do have aliases for various commands, such as /image /video will trigger for the media block. But your bug report is a bit all encompassing that it's not clear what is truly being requested.
Sorry for being that vague, What I want is a fuzzy matching or similar search capabilities. Like
Word-Boundary/Acronym Search: Match against word initialisms (matching the first letter of each word in a space-separated string) so that typing
/h1matches Heading 1.And sorry for extending it this long.
I see it as necessary. I don't think adding a few other options is going to results in a ton of false matches. Doing
h1is fairly common for apps like this (including Anytype).