this post was submitted on 27 Oct 2023
1 points (100.0% liked)

Emacs

311 readers
1 users here now

A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!

Get Emacs

Rules

  1. Posts should be emacs related
  2. Be kind please
  3. Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.

Emacs Resources

Emacs Tutorials

Useful Emacs configuration files and distributions

Quick pain-saver tip

founded 1 year ago
MODERATORS
rglullis@communick.news
raphael@communick.news
1
Possible to use fd or some other faster search tool than find with consult (alien.top)
submitted 1 year ago by ethanzanemiller@alien.top to c/emacs@communick.news
4 comments fedilink hide all child comments
 

I have been using `find` with `consult-find`, but it's a bit slow. I'm wondering if it would be possible to speed it up using some other tool such as `fd`. I noticed that the consult README talks about `consult-fd` but I cannot locate that function anywhere in my version which is I think the latest `0.35`. Can anyone help with this?

Also, similarly, consult-grep is a bit slow. Wondering if one can swap in `ag` for example?

top 4 comments
sorted by: hot top controversial new old
[–] redblobgames@alien.top 1 points 1 year ago

I do see a consult-fd in 0.35. But otherwise, you might try changing consult-find-args to point to fd instead of find.

For faster grep, I've been using consult-ripgrep. For me, ripgrep has been faster than ag.

[–] troll-gpt@alien.top 1 points 1 year ago

consult-fd exists in the code, see code.

consult-ripgrep also exists in the code, see code.

When did you last update your package?

[–] varsderk@alien.top 1 points 1 year ago

https://github.com/minad/consult#grep-and-find

See consult-fd and consult-ripgrep

[–] 7890yuiop@alien.top 1 points 1 year ago

In general, if the alternative tools use the same CLI options (at least for Emacs' purposes) and produce the same output format as the original tools, there would be no reason why you couldn't swap out one for the other in the elisp code (or, quite likely, set a variable for the location of that original program to instead point to the alternative).

If those things are not true, it may be necessary to support them explicitly in the lisp code.