output: remove --line-number-width flag

This commit does what no software project has ever done before: we've
outright removed a flag with no possible way to recapture its
functionality.

This flag presents numerous problems in that it never really worked well
in the first place, and completely falls over when ripgrep uses the
--no-heading output format. Well meaning users want ripgrep to fix this
by getting into the alignment business by buffering all output, but that
is a line that I refuse to cross.

Fixes #795
This commit is contained in:
Andrew Gallant
2018-04-23 19:57:22 -04:00
parent ed059559cd
commit ae6f871491
5 changed files with 1 additions and 65 deletions

View File

@@ -56,7 +56,6 @@ pub struct Args {
invert_match: bool,
line_number: bool,
line_per_match: bool,
line_number_width: Option<usize>,
max_columns: Option<usize>,
max_count: Option<u64>,
max_filesize: Option<u64>,
@@ -191,8 +190,7 @@ impl Args {
.only_matching(self.only_matching)
.path_separator(self.path_separator)
.with_filename(self.with_filename)
.max_columns(self.max_columns)
.line_number_width(self.line_number_width);
.max_columns(self.max_columns);
if let Some(ref rep) = self.replace {
p = p.replace(rep.clone());
}
@@ -401,7 +399,6 @@ impl<'a> ArgMatches<'a> {
ignore_files: self.ignore_files(),
invert_match: self.is_present("invert-match"),
line_number: line_number,
line_number_width: try!(self.usize_of("line-number-width")),
line_per_match: self.is_present("vimgrep"),
max_columns: self.usize_of_nonzero("max-columns")?,
max_count: self.usize_of("max-count")?.map(|n| n as u64),