fix: use more appropriate snacks picker #199
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, debugprint uses the function snacks.picker.grep to find usages of "DEBUGPRINT" (or other custom print markers). In my opinion this is not the most appropriate picker offered by snacks.
The reason for this is that
picker.grepsimply writesDEBUGPRINTinto a grep picker as if it were user input, whilepicker.grep_wordpreloads the grep picker with a given string in a separate way.This is important since, in the current version, if a user opens the picker for debugprints and wants to match a given file, they first need to complete the rest of the input starting from the end of the debugprint marker. (see imgs 1 and 2).
This is the naive search, user opened the debug prints picker and wrote

debug(to match the file). No results shown as the prompt starts fromDEBUGPRINT.This search correctly retrieves results, but requires the user start with a wildcard.
This final image is the different function that is present in the PR, not only is it displayed differently by Snacks itself, such that the debugprint marker can't be deleted, but even a naive search (like img 1) displays results as the debugprint marker and the user expression are evaluated separately. Do note that if the user has smart-case enabled (such as my case), it will now match lower-case strings, as apparently the smart-case is not triggered by the upper-case debugprint marker.
Let me finish by saying that I love this plugin and I use it daily, this is just a minor nitpick that I have and wanted to fix for myself, and decided to open a PR for it in case you find it useful. If there's anything I need to change to get this merged let me know, and if for some reason you don't find this PR useful feel free to close it. Thanks!