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

Size of output is 5 times bigger with ripgrep than with thesilversearcher for color=always #764

Closed
edi9999 opened this issue Jan 29, 2018 · 4 comments · Fixed by #1017
Closed
Labels
bug A bug.

Comments

@edi9999
Copy link

edi9999 commented Jan 29, 2018

This is very similar to this issue : #696.

But I think I found out what the underlying problem is.

rg --color always --colors line:fg:yellow --colors line:style:bold --colors path:fg:green --colors path:style:bold --colors match:fg:black --colors match:bg:yellow --colors match:style:nobold '.' --no-heading --line-number >/tmp/foo_rg
ag '.' --color --nogroup --column > /tmp/foo_ag

When I then run :

cat /tmp/foo_rg | less -R
# and 
cat /tmp/foo_ag | less -R

I see that the output colors are "similar", but the size of the files are very different :

ls -lah /tmp/foo*
-rw-r--r-- 1 edgar edgar  22M Jan 29 10:48 /tmp/foo_ag
-rw-r--r-- 1 edgar edgar 109M Jan 29 10:48 /tmp/foo_rg

And the number of lines in each file is the same.

I have taken a screenshot of the same lines of each efile for api/check.py:
On top is the ripgrep output, On the bottom the ag output :

selection_001

As you can see, ripgrep has a huge amount of escape sequences that ag doesn't have.

@edi9999 edi9999 changed the title Size of output is 10 times bigger with ripgrep than with thesilversearcher for color=always Size of output is 5 times bigger with ripgrep than with thesilversearcher for color=always Jan 29, 2018
@okdana
Copy link
Contributor

okdana commented Jan 29, 2018

That doesn't seem ideal, but it's only relevant in cases where rg has been asked to match individual characters — e.g., patterns like . and \w. .* for example does not have that problem (though rg is still a little more noisy with the format stuff than ag because it doesn't combine sequences).

I don't use fzf but it doesn't seem likely that the original reporter from #696 would have been searching for a pattern like . (right?). Maybe there could be some interplay between the way rg outputs sequences and whatever fzf does with them, though, idk

@BurntSushi
Copy link
Owner

This is indeed interesting! I agree that we should probably fix this. It might make sense to delay fixing this until the printer is refactored though.

@edi9999
Copy link
Author

edi9999 commented Jan 29, 2018

Yes, the usecase in fzf is really to query with . , this way, we actually have all lines which we then filter throuhg fzf (which is an interactive grep). I find it good to be able to search for . because this makes the search more interactive, if for example I type seacr instead of searc, I will see immediately that there are no more results.

@okdana
Copy link
Contributor

okdana commented Jan 29, 2018

Ohh. That makes sense then

@BurntSushi BurntSushi added the bug A bug. label Feb 1, 2018
BurntSushi added a commit that referenced this issue Aug 19, 2018
This commit updates the CHANGELOG to reflect all the work done to make
libripgrep a reality.

* Closes #162 (libripgrep)
* Closes #176 (multiline search)
* Closes #188 (opt-in PCRE2 support)
* Closes #244 (JSON output)
* Closes #416 (Windows CRLF support)
* Closes #917 (trim prefix whitespace)
* Closes #993 (add --null-data flag)
* Closes #997 (--passthru works with --replace)

* Fixes #2 (memory maps and context handling work)
* Fixes #200 (ripgrep stops when pipe is closed)
* Fixes #389 (more intuitive `-w/--word-regexp`)
* Fixes #643 (detection of stdin on Windows is better)
* Fixes #441, Fixes #690, Fixes #980 (empty matching lines are weird)
* Fixes #764 (coalesce color escapes)
* Fixes #922 (memory maps failing is no big deal)
* Fixes #937 (color escapes no longer used for empty matches)
* Fixes #940 (--passthru does not impact exit status)
* Fixes #1013 (show runtime CPU features in --version output)
BurntSushi added a commit that referenced this issue Aug 20, 2018
This commit updates the CHANGELOG to reflect all the work done to make
libripgrep a reality.

* Closes #162 (libripgrep)
* Closes #176 (multiline search)
* Closes #188 (opt-in PCRE2 support)
* Closes #244 (JSON output)
* Closes #416 (Windows CRLF support)
* Closes #917 (trim prefix whitespace)
* Closes #993 (add --null-data flag)
* Closes #997 (--passthru works with --replace)

* Fixes #2 (memory maps and context handling work)
* Fixes #200 (ripgrep stops when pipe is closed)
* Fixes #389 (more intuitive `-w/--word-regexp`)
* Fixes #643 (detection of stdin on Windows is better)
* Fixes #441, Fixes #690, Fixes #980 (empty matching lines are weird)
* Fixes #764 (coalesce color escapes)
* Fixes #922 (memory maps failing is no big deal)
* Fixes #937 (color escapes no longer used for empty matches)
* Fixes #940 (--passthru does not impact exit status)
* Fixes #1013 (show runtime CPU features in --version output)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants