Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fuzzy searching not working in counsel-ag and counsel-rg #1801

Closed
diamond-lizard opened this issue Nov 13, 2018 · 13 comments

Comments

@diamond-lizard
Copy link

commented Nov 13, 2018

When I run counsel-ag or counsel-rg and the Control-o menu shows that m: matcher fuzzy, I expect for matching to be fuzzy, but it's not.

For instance, if I have some files that contain the text with-eval-after-load, I expect to be able to search for weal and have the lines containing with-eval-after-load match, but instead I see No matches found.

@Alexander-Shukaev

This comment has been minimized.

Copy link

commented Nov 21, 2018

By the way, not related to this issue, but I could not figure out how to use counsel-ag and counsel-rg properly at all. They are completely different from counsel-grep in the behavior in a sense that they don't interactively ask me which directory to being search from or which file patterns to consider. As a result, I simply don't understand what they are searching for when I type pattern. For example, I tried to invoke both from the root directory of one of my projects and type some pattern which obviously exists in nearly every file and got nothing in the results, while typing some random symbols gave me some weird matches only in one file which I would never even expect. Perhaps I'm too dumb to understand all that but in the end how the hell do you use these search utilities via counsel interface?

@basil-conto

This comment has been minimized.

Copy link
Collaborator

commented Nov 21, 2018

@Alexander-Shukaev The various Counsel search commands have either been authored or extended completely separately and by different authors over time, and there are many inconsistencies between them. For example, some of them are completely stand-alone, whereas others, like counsel-rg, are built on top of counsel-ag. The discussions in #1408 and #1559 are examples of such discrepancies being acknowledged. These issues are further compounded by the fact that most Counsel search functionality relies on the shell, which brings a slew of further system- and/or shell-dependent issues to light.

That said, whenever you come across a bug or surprising behaviour, please search the issue tracker for relevant past discussions and try to report clear, detailed, self-contained (i.e. report one issue at a time), and reproducible recipes, because vague, non-reproducible descriptions are not very actionable, to put it mildly.

@Alexander-Shukaev

This comment has been minimized.

Copy link

commented Nov 21, 2018

I understand that, my point was not to report a bug as I cannot judge whether this is a bug or not. I just wanted to spark a discussion with people who use these new search utilities via counsel, and since I know that support for those exists in counsel for quite some time, I would have expected people already enjoy them at full speed, while I was left behind with my misunderstanding on how to actually use them. That is I had an impression that if a person created a ticket for an issue on rg, then this person must have used it a lot and can share his/her workflow.

@basil-conto

This comment has been minimized.

Copy link
Collaborator

commented Nov 22, 2018

Fair enough, thanks for clarifying. As is the case for the different values of ivy-re-builders-alist, different Counsel search commands have their own "camp" of users/adherents who are usually more motivated to work only on a particular subset of the search commands, thus giving rise to disparate behaviour/bugs/etc.

At the end of the day, though, all Counsel search commands "work" within certain boundaries OOTB, so if something isn't working for you then by all means please do report it properly.

@diamond-lizard

This comment has been minimized.

Copy link
Author

commented Nov 22, 2018

By the way, not related to this issue, but I could not figure out how to use counsel-ag and counsel-rg properly at all. They are completely different from counsel-grep in the behavior in a sense that they don't interactively ask me which directory to being search from or which file patterns to consider. As a result, I simply don't understand what they are searching for when I type pattern.

I usually use a hydra to call counsel-ag from whatever the current directory for my buffer is, like so: (counsel-ag nil default-directory).

If instead of doing that you call counsel-ag interactively, without any arguments, I believe it will run this code:

  (let ((default-directory (or initial-directory
                               (locate-dominating-file default-directory ".git")
                               default-directory)))

Which, if I'm not mistaken, will search up from the current directory until it finds a .git file (or directory, rather), and search from there.

For me that yields too many results, so I like to limit the searches to be from the current directory inistead.

If you wanted to be a bit fancier about it, I guess you could first prompt the user for a directory to search in, and call counsel-ag with that directory as an argument.

@basil-conto

This comment has been minimized.

Copy link
Collaborator

commented Nov 22, 2018

If you wanted to be a bit fancier about it, I guess you could first prompt the user for a directory to search in, and call counsel-ag with that directory as an argument.

counsel-ag already does this when called with a prefix argument C-u.

@abo-abo

This comment has been minimized.

Copy link
Owner

commented Nov 22, 2018

When I run counsel-ag or counsel-rg and the Control-o menu shows that m: matcher fuzzy, I expect for matching to be fuzzy, but it's not.

This is expected behavior, not a bug. With counsel-rg, the filtering takes place /outside/ Emacs, it's done by the ripgrep binary. Matchers, fuzzy or otherwise are Elisp, they have no influence on the ripgrep binary.

This can't be changed, short of re-implementing ripgrep in pure Elisp. You can imagine the performance impact:)

@Alexander-Shukaev you likely have a rare issue related either to your config or your shell. You can test counsel-rg by doing a make plain from this repository, maybe additionally using the bash shell. If you manage to pinpoint a bug reproduction scenario, please open a new issue.

@abo-abo abo-abo closed this Nov 22, 2018

@diamond-lizard

This comment has been minimized.

Copy link
Author

commented Nov 22, 2018

When I run counsel-ag or counsel-rg and the Control-o menu shows that m: matcher fuzzy, I expect for matching to be fuzzy, but it's not.

This is expected behavior, not a bug. With counsel-rg, the filtering takes place /outside/ Emacs, it's done by the ripgrep binary. Matchers, fuzzy or otherwise are Elisp, they have no influence on the ripgrep binary.

This can't be changed, short of re-implementing ripgrep in pure Elisp. You can imagine the performance impact:)

The pattern passed to ripgrep/ag is already fully within the control of Emacs. Nothing need be reimplemented. Unless I'm misunderstanding something, then when fuzzy matching is enabled, all that has to be done is to pass to ripgrep/ag a .* between each character of the user's search term. Performance should be unaffected, because ripgrep/ag will still be doing all the searching.

abo-abo added a commit that referenced this issue Nov 24, 2018
@abo-abo

This comment has been minimized.

Copy link
Owner

commented Nov 24, 2018

@diamond-lizard Good point. I've made the adjustment, please test it. I can't say that I'm happy with using a fuzzy matcher for ripgrep - there are way too many results, all for the cost of not having to put 1-2 spaces in the search string. But maybe the trade-off is worthwhile to other users.

@diamond-lizard

This comment has been minimized.

Copy link
Author

commented Nov 24, 2018

@abo-abo Fantastic. This works perfectly, and is exactly what I was looking for. Thank you so much!

@Alexander-Shukaev

This comment has been minimized.

Copy link

commented Nov 24, 2018

Nice one! By the way, I figured out why one some repositories ag and rg didn't produce any results. The following customization fixes the problem:

  (setq-default
    counsel-ag-base-command (format counsel-ag-base-command "--hidden %s")
    counsel-rg-base-command (format counsel-rg-base-command "--hidden %s"))

Use with care, i.e. unless you have .ignore and/or .agignore and/or .rgignore set up.

@diamond-lizard

This comment has been minimized.

Copy link
Author

commented Nov 24, 2018

@abo-abo:

I can't say that I'm happy with using a fuzzy matcher for ripgrep - there are way too many results

To narrow down the results, one could simply type more or switch to a different matcher.

Using fuzzy matching is just a different workflow -- one that I personally find very useful, but sometimes I do need to switch to a different matcher.

It's great that counsel/swiper has the flexibility to approach searching in all these different ways.

@Alexander-Shukaev

This comment has been minimized.

Copy link

commented Nov 24, 2018

Partially related to #1812, where I still have to respond and will do ASAP, but the basic idea is that we need some smart ranking/sorting algorithm on top of the results returned from anywhere (e.g. rg or ag in this case).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.