5 ms·

I like that you mentioned `bat` and `ag`, two of many favorite CLI tools. Others you might want to checkout not necessarily for writing a book but general CLI

I like that you mentioned `bat` and `ag`, two of many favorite CLI tools. Others you might want to checkout not necessarily for writing a book but general CLI pleasantness: - fzf (https://github.com/junegunn/fzf https://github.com/junegunn/fzf) - autojump (https://github.com/wting/autojump https://github.com/wting/autojump) - jq (https://stedolan.github.io/jq/ https://stedolan.github.io/jq/) - fd (https://github.com/sharkdp/fd https://github.com/sharkdp/fd)

grimgrin 8y ago
Many interested in autojump could probably get what they want out of nice, pure https://github.com/rupa/z https://github.com/rupa/z Here's an alternative to fzf, for comparison's sake: https://github.com/jhawthorn/fzy https://github.com/jhawthorn/fzy
dredmorbius 8y ago
jq's a useful utility, but I'm curious as to how you're using a JSON query tool in writing.
ipozgaj 8y ago
If you use and like `ag`, I suggest taking a look at ripgrep (`rg`). It seems to be by far the fastest out of three (`ack`, `ag`, `rg`). And it has a pretty interesting codebase (written in Rust).
- Myrmornis 8y ago
  If you're working in a git repository then IMO the most appropriate search tool is simply `git grep`. I don't think there's any reason to use ripgrep, ag, ack etc in that situation. (Personally, if I'm working with text files, then I'm nearly always in a git repo.)
  - burntsushi 8y ago
    (author of ripgrep here) Well at least one reason is because ripgrep is faster. On simple literal queries they'll have comparable speed, but beyond that, `git grep` is _a lot_ slower. Here's an example on a checkout of the Linux kernel: $ time rg '\w+_PM_RESUME' | wc -l 8 real 0.127 user 0.689 sys 0.589 maxmem 19 MB faults 0 $ time LC_ALL=C git grep -E '\w+_PM_RESUME' | wc -l 8 real 4.607 user 28.059 sys 0.442 maxmem 63 MB faults 0 $ time LC_ALL=en_US.UTF-8 git grep -E '\w+_PM_RESUME' | wc -l 8 real 21.651 user 2:09.54 sys 0.413 maxmem 64 MB faults 0 ripgrep supports Unicode by default, so it's actually comparable to the LC_ALL=en_US.UTF-8 variant. There are other reasons. It is nice to use a single tool for searching in all circumstances. ripgrep can fit that role. Maybe you don't know, but ripgrep respects your .gitignore file.
    - Myrmornis 8y ago
      Thanks! I knew ripgrep was praised in particular for its performance but I didn't know the difference was that large. The repo I usually work in has 8.7M lines of code and I had been finding `git grep` performance very adequate (I use it in combination with the Emacs helm library where it forms part of an incremental search UI, and hence gets called multiple times in quick succession in response to changing search input.) It looks like it will be fun to try swapping in ripgrep as the helm search backend; I'll try it.

grimgrin 8y ago

Many interested in autojump could probably get what they want out of nice, pure https://github.com/rupa/z https://github.com/rupa/z Here's an alternative to fzf, for comparison's sake: https://github.com/jhawthorn/fzy https://github.com/jhawthorn/fzy

dredmorbius 8y ago

jq's a useful utility, but I'm curious as to how you're using a JSON query tool in writing.

ipozgaj 8y ago

If you use and like `ag`, I suggest taking a look at ripgrep (`rg`). It seems to be by far the fastest out of three (`ack`, `ag`, `rg`). And it has a pretty interesting codebase (written in Rust).

Myrmornis 8y ago
If you're working in a git repository then IMO the most appropriate search tool is simply `git grep`. I don't think there's any reason to use ripgrep, ag, ack etc in that situation. (Personally, if I'm working with text files, then I'm nearly always in a git repo.)
- burntsushi 8y ago
  (author of ripgrep here) Well at least one reason is because ripgrep is faster. On simple literal queries they'll have comparable speed, but beyond that, `git grep` is _a lot_ slower. Here's an example on a checkout of the Linux kernel: $ time rg '\w+_PM_RESUME' | wc -l 8 real 0.127 user 0.689 sys 0.589 maxmem 19 MB faults 0 $ time LC_ALL=C git grep -E '\w+_PM_RESUME' | wc -l 8 real 4.607 user 28.059 sys 0.442 maxmem 63 MB faults 0 $ time LC_ALL=en_US.UTF-8 git grep -E '\w+_PM_RESUME' | wc -l 8 real 21.651 user 2:09.54 sys 0.413 maxmem 64 MB faults 0 ripgrep supports Unicode by default, so it's actually comparable to the LC_ALL=en_US.UTF-8 variant. There are other reasons. It is nice to use a single tool for searching in all circumstances. ripgrep can fit that role. Maybe you don't know, but ripgrep respects your .gitignore file.
  - Myrmornis 8y ago
    Thanks! I knew ripgrep was praised in particular for its performance but I didn't know the difference was that large. The repo I usually work in has 8.7M lines of code and I had been finding `git grep` performance very adequate (I use it in combination with the Emacs helm library where it forms part of an incremental search UI, and hence gets called multiple times in quick succession in response to changing search input.) It looks like it will be fun to try swapping in ripgrep as the helm search backend; I'll try it.