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

add support for persistent config #772

Merged
merged 6 commits into from
Feb 4, 2018
Merged

Conversation

BurntSushi
Copy link
Owner

This PR fixes both #196 and #553. The commit messages have most of the details (including some goodies like a 2x decrease in release build time), but the TL;DR is that ripgrep now recognizes a RIPGREP_CONFIG_PATH environment variable. When set and non-empty, ripgrep will read shell arguments from it (one per line) and prepend them to whatever explicit CLI arguments have been given. A new flag, --no-config, prevents any sort of configuration from being loaded from a file.

This does not add any support for auto-loading config files from pre-determined locations like one's $XDG_CONFIG_HOME directory. It was decided to punt on that for now, and one wonders how far we can get with just the env var approach!

This commit updates the `log` crate to 0.4 and drops the dependency on
env_logger. In particular, the latest version of env_logger brings in
additional non-optional dependencies such as chrono that I don't think is
worth including into ripgrep.

It turns out ripgrep doesn't need any fancy logging. We just need a concept
of log levels and the ability to print to stderr. Therefore, we just roll
our own super simple logger.

This update is motivated by the persistent configuration task. In
particular, we need the ability to toggle the global log level more than
once, and this doesn't appear to be possible with older versions of the
log crate.
This commit makes the git hash ripgrep was built with available for use
in the version string.

We also do a few minor touchups in build.rs and src/app.rs.
This removes the vec-map feature from clap. clap's README claims that
vec-map provides a small performance benefit, but I could observe any in
ripgrep workloads.

The benefit here is that it drops a dependency.

Amazingly, this drops whole release build times for ripgrep from 68s to
33s, and debug build time also decreases from 22s to 15.5s. This was
entirely unintentional but a welcome surprise.
This commit refactors how we define flags. In theory, this commit
should not result in any behavioral changes (other than perhaps more
consistent rules for flag overrides).

There are two important changes:

Firstly, each flag (or tightly coupled group of flags) is defined in its
own function. This function includes the documentation for that flag. This
improves the locality for each flag; everything you need to know about it
is self-contained in one small region of code.

Secondly, each flag is defined in terms of a very small ripgrep-specific
layer above clap. This permits us to have a set of structured arguments
independent of clap. The intention here is that we can use this indirection
to generate other documentation such as man pages.

This commit lays the ground work for modifying our use of clap in
principled way such that flags can be specified multiple times without
conflict. This in turn will help us implement support for persistent
configuration.
This commit builds on the previous argv refactor by being more principled
about how we declared our flags. In particular, we now require that every
clap argument is one of three things: a positional argument, a switch or
a flag that accepts exactly one value. The latter two are always permitted
to be repeated, and we modify the code that consumes a clap::ArgMatches to
always use the *last* value of an argument. (clap by default always uses
the first value of argument, if it has been repeated and is accessed via
one of the singleton accessors.)

Fixes #553
@okdana
Copy link
Contributor

okdana commented Feb 4, 2018

To fix the completion-function check you can add this to _rg (around line 55):

"--no-config[don't read configuration files]"

This commit adds support for reading configuration files that change
ripgrep's default behavior. The format of the configuration file is an
"rc" style and is very simple. It is defined by two rules:

  1. Every line is a shell argument, after trimming ASCII whitespace.
  2. Lines starting with '#' (optionally preceded by any amount of
     ASCII whitespace) are ignored.

ripgrep will look for a single configuration file if and only if the
RIPGREP_CONFIG_PATH environment variable is set and is non-empty.
ripgrep will parse shell arguments from this file on startup and will
behave as if the arguments in this file were prepended to any explicit
arguments given to ripgrep on the command line.

For example, if your ripgreprc file contained a single line:

    --smart-case

then the following command

    RIPGREP_CONFIG_PATH=wherever/.ripgreprc rg foo

would behave identically to the following command

    rg --smart-case foo

This commit also adds a new flag, --no-config, that when present will
suppress any and all support for configuration. This includes any future
support for auto-loading configuration files from pre-determined paths
(which this commit does not add).

Conflicts between configuration files and explicit arguments are handled
exactly like conflicts in the same command line invocation. That is,
this command:

    RIPGREP_CONFIG_PATH=wherever/.ripgreprc rg foo --case-sensitive

is exactly equivalent to

    rg --smart-case foo --case-sensitive

in which case, the --case-sensitive flag would override the --smart-case
flag.

Closes #196
@BurntSushi
Copy link
Owner Author

@okdana Yup! Figured it out. :-) I'm quite happy that CI caught that! I completely forgot we even had the test.

@BurntSushi BurntSushi merged commit c57d0fb into master Feb 4, 2018
@BurntSushi BurntSushi deleted the ag/persistent-config branch February 4, 2018 15:40
@hoodie
Copy link
Contributor

hoodie commented Feb 12, 2018

this is a neat feature, but it falls down if you install from crates.io:

ripgrep 0.8.0 (rev )

@BurntSushi
Copy link
Owner Author

@hoodie Thanks, I created #789. It is low priority though.

@BatmanAoD
Copy link

@BurntSushi Just wanted to say that 0.8 is a great update; I just migrated to Windows 10 so it's great to have native colors in cmd, and the persistent config is very nice. Thanks for the awesome tool!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants