maximum line length - Githubissues

BurntSushi / ripgrep

ripgrep recursively searches directories for a regex pattern while respecting your gitignore

The Unlicense

49k stars 2.01k forks source link

maximum line length #129

Closed BurntSushi closed 7 years ago

BurntSushi commented 8 years ago

I'd like ripgrep to have the ability to either hide or trim lines that are very long. Some lines take up my entire screen and are borderline useless to look at. It's possible that finding an intelligent way to shorten them would be best, since my guess is that the actual matched text is much smaller than the full line. However, this is harder to implement.

I don't think this should be enabled by default. It seems a little surprising for ripgrep to hide lines like that. In general, I like the work flow of, "run a search, see huge lines, confirm that I don't care about them and run ripgrep again with an option to hide them." It may however be plausible to enable this limit if results are being dumped to a terminal (we already enable colors, line numbers and file headings).

forgottenswitch commented 7 years ago

Of course, something that actually ellipsizes long lines and prints them as "... context match1 context ... context match2 context ..." would be better, but then as you discussed above things quickly become really complicated because unicode.

I posted implementation above; it does not seem to be so.

RalfJung commented 7 years ago

Wow, impressive! That does look nice indeed. I somehow missed these links before, sorry.

BurntSushi commented 7 years ago

I would like to avoid the contextual display. That should be a separate issue. I do not want to bring that code (if at all) until libripgrep is done. The code and the feature are too complex.

@RalfJung I don't have rock solid answers for your questions, but here's an attempt:

If the -r/--replace flag is used, then ignoring --max-width doesn't seem quite right. I think it should still be applied to the result of the replacement.
ripgrep has no internationalization.
We can bikeshed in the PR.
I'm not sure about the eol writing. I'd have to look more closely.
For context lines, I think printing something like "context line omitted because of --max-width" is reasonable.

RalfJung commented 7 years ago

If the -r/--replace flag is used, then ignoring --max-width doesn't seem quite right. I think it should still be applied to the result of the replacement.

So should it also still show the number of matches? That'd be extra work, unless there is a way I don't know about to get this from re.replace_all.

BurntSushi commented 7 years ago

@RalfJung re.replace_all accepts anything that satisfies the regex::bytes::Replacer trait (including FnMut(&Captures) -> Vec<u8> or your own type), which should enable you to both do the replacement and count the number of times it occurred.

RalfJung commented 7 years ago

Right, I could use a closure or implement the trait for a custom type that also does the counting... but that will cost some performance, it seems, since we want to be called for every match and hence cannot use the no_expansion optimization.