Inherit config from RIPGREP_CONFIG_PATH

[fresh2dev]

Thanks for making repgrep, it is very capable and intuitive!

Ripgrep allows default settings to be stored in a configuration file, identified by an env. var named RIPGREP_CONFIG_PATH.

For example, I have the following in my ripgrep config file:

# Search hidden files and directories.
--hidden

# Follow symbolic links.
--follow

# Exclude directories.
--glob=!{.git}

# Sort by file path.
--sort=path

These settings don't seem to be picked up by repgrep. Would it take much for repgrep to recognize this config file?

[acheronfail]

This is definitely something I've considered doing (I even left a few comments in the code about it...).

But it's a little tricky with the APIs that clap provides. I'll have another crack at this when I get the chance.

[acheronfail]

Here's a great commit from ripgrep about its command line parsing: https://github.com/BurntSushi/ripgrep/commit/082245dadb3854238e62b91aa95a46018cf16ef1... Might take inspiration from that when I look into this more.

[acheronfail]

Initial branch here: https://github.com/acheronfail/repgrep/commit/fae11bc85a789513a6ad61bc3cc8479f4a5adeb1

[acheronfail]

Currently merged to next. Still missing a few things before I'll make a release though!

Feel free to test it out with

cargo install --git https://github.com/acheronfail/repgrep --branch next

And let me know if it works for you.

[fresh2dev]

Thanks for your attention and work on this issue. I later saw the comment in the code next to the explicit flag --no-config.

TBH, I was surprised to see the explicit disabling of the config file, and the fact that it requires any work from you to support it. My thinking is that ripgrep just picks it up and uses it, and since you're wrapping around ripgrep, repgrep shouldn't even need to peek into the config file.

After reading this -- https://github.com/acheronfail/repgrep/pull/99#issuecomment-1858768461 -- I see now that repgrep needs to intercept some command-line flags, like --pattern or --encoding.

As a user, I hope that repgrep provides as thin of a wrapper around ripgrep as possible, both to allow for native capability like respecting RIPGREP_CONFIG_PATH, and also to not disrupt/interfere with any native functionality (like the risk of repgrep parsing command-line flags differently than ripgrep would). That and it eases the development burden (less code is more maintainable code).

I read through the in-program help and saw explicit mentions of --no-config and support of RGR_JSON_FILE. After reading that, I threw this into my shell profile:

rgi() {
    TMPFILE=$(mktemp) && rg "$@" --json > $TMPFILE && RGR_JSON_FILE=$TMPFILE rgr
}

This seems to accomplish my goals of relying on native ripgrep as much as possible, and relying on repgrep solely for the interactive replacement UI (which I love, TYSM :star_struck:). While empowering, I understand this approach does not prevent me (the user) from shooting myself in the foot with unsupported flags (--binary, --files, etc.).

As a user with basic needs (replacing strings throughout utf-8 encoded text files), I'm undecided as to whether it is better to use this shell function vs. rely directly on repgrep. Am I losing out on any significant functionality with this little shell function?

[acheronfail]

As a user with basic needs (replacing strings throughout utf-8 encoded text files), I'm undecided as to whether it is better to use this shell function vs. rely directly on repgrep. Am I losing out on any significant functionality with this little shell function?

Only downsides of that approach are:

• possibly printing terminal characters with --binary (as you've mentioned)
• potential issues when using --fixed-strings (as I haven't tested it yet - rgr currently assumes all patterns are regular expressions, but --fixed-strings makes them substring searches)
• EDIT: you will not be able to use capturing groups in your replacement, since rgr won't know what the pattern you used was (I'm also looking into fixing this in the upcoming version...)

Sounds like your rgi() {...] shell function will suit your needs perfectly.

As an aside though, I've taken this opportunity to make rgr an even thinner wrapper (before it was more opinionated) so once I do some tests and any minor changes for --fixed-strings I'll release 0.15 which should also work for your use-case. (Also passing --file is supported with the changes I've made to the next branch right now.)

Either way, use your rgi or the next version, the choice is yours! 🙂

[fresh2dev]

Ok, good to know, and I appreciate you sharing that insight. I do use capture-groups. I'll give the next version a go; thank you!

[acheronfail]

Should be fixed in 0.15