You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using the command palette, ordering of results fails to take into account adjacency of characters.
Whether this is a bug report or a feature request really depends on whether effort was already made to make the search results account for adjacency or not. The only other issue I can find related to this is #21019, but that seems to be dealing with a different matter, so I will include version information, but I'm proceeding under the premise that this is a request for a new feature rather than a bug report.
The case for the value of this feature
Although the ability to search through commands without having to type in every consecutive character is valuable, it seems to me that users will virtually never want or expect the results of their search to prioritize results with a disconnected match above results with a connected match. In the image above, I typed "vim" and expected to see all commands related to Vim mode at the top of the list. I cannot imagine a case where I would type in the characters vim and expect "View: Minimize Other Editor Groups" at the top of the list. If I were looking for "View: Minimize Other Editor Groups", I would expect to have to type more characters, and certainly be prepared to do so. I would most likely type view:moeg—unless the command I wanted rose to the top before I finished typing that.
Hopefully the example I've given is enough to demonstrate that the behavior I'm describing would be preferable. But if I've left any questions unanswered, please ask for more information.
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
When using the command palette, ordering of results fails to take into account adjacency of characters.
Whether this is a bug report or a feature request really depends on whether effort was already made to make the search results account for adjacency or not. The only other issue I can find related to this is #21019, but that seems to be dealing with a different matter, so I will include version information, but I'm proceeding under the premise that this is a request for a new feature rather than a bug report.
The case for the value of this feature
Although the ability to search through commands without having to type in every consecutive character is valuable, it seems to me that users will virtually never want or expect the results of their search to prioritize results with a disconnected match above results with a connected match. In the image above, I typed "vim" and expected to see all commands related to Vim mode at the top of the list. I cannot imagine a case where I would type in the characters vim and expect "View: Minimize Other Editor Groups" at the top of the list. If I were looking for "View: Minimize Other Editor Groups", I would expect to have to type more characters, and certainly be prepared to do so. I would most likely type view:moeg—unless the command I wanted rose to the top before I finished typing that.
Hopefully the example I've given is enough to demonstrate that the behavior I'm describing would be preferable. But if I've left any questions unanswered, please ask for more information.
Thanks!
Steps to Reproduce:
The text was updated successfully, but these errors were encountered: