Ripgrep04 Aug 2017
Lately, due to working with a large code base, I've grown more and
more fond of
counsel-rg. It's an Elisp wrapper
around ripgrep - a relatively
new recursive grep tool that aims to be faster than the competition
Besides being really fast,
rg also has some really
One such switch is especially useful for Emacs:
-M, --max-columns NUM : Don't print lines longer than this limit in bytes. Longer lines are omitted, and only the number of matches in that line is printed.
-M switch is useful twofold:
- Emacs is slow when dealing with long lines (by long I mean thousands of chars per line)
- Emacs is slow at accepting a huge amount of output from a process
For each character you add to your input,
counsel-rg starts a new
shell command to recalculate the matches with the new input. This
means that in order to avoid keyboard lag there's only about 0.1
seconds available for both:
- Running the shell command.
- Accepting output from the shell command.
So I'm quite happy that
rg speeds up both steps. Less time spent on
these steps provides for much smoother searching.
I also work with large log files, one file at a time. For a long time,
counsel-grep-or-swiper as my main search command:
(global-set-key (kbd "C-s") 'counsel-grep-or-swiper)
But for a 40Mb log file with really long lines
counsel-grep-or-swiper started to lag a bit. I tried
and it was actually faster than
grep, although it was searching the
whole directory. So I thought, why not use
rg instead of
switch is actually really easy and required only a simple user
(setq counsel-grep-base-command "rg -i -M 120 --no-heading --line-number --color never '%s' %s")
If you haven't tried
ripgrep so far, I suggest you give it a go. Happy hacking!
And if you're a C hacker and have some free time on your hands, why not look at the long lines and the process output issues in Emacs? I'd be very grateful:)