ripgrep: --color does not work under Emacs

I’m using rg 0.2.1 and Emacs 25. It looks like --color doesn’t have effect under Emacs, while other tools such as grep works.

M-! echo hello | grep --color=always hello gives [01;31m[Khello[m[K
M-! echo hello | rg --color=always hello gives hello (where is the escape code?)

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 28 (17 by maintainers)

Commits related to this issue

Completely re-work colored output and tty handling. This commit completely guts all of the color handling code and replaces most of it with two new crates: wincolor and termcolor. wincolor provides a... — committed to BurntSushi/ripgrep by BurntSushi 8 years ago
Use basic SGR sequences when possible. In Emacs, its terminal apparently doesn't support "extended" sets of foreground/background colors. Unless we need to set an "intense" color, we should instead u... — committed to BurntSushi/ripgrep by BurntSushi 7 years ago

Most upvoted comments

Andrew Gallant notifications@github.com writes:

All right, this should finally be fixed in master. I hope to get a release out soon.

I installed rust and builded rg from master, and I can confirm rg is now outputing colors as expected 😃.

Many thanks for your quick fix and for rg!

– Thierry

thierryvolpiatto on Jan 14, 2017

Andrew Gallant notifications@github.com writes:

@thierryvolpiatto @xuchunyang I think the bottom line here is that while ripgrep is technically respecting the letter of the law, it doesn’t actually match up with user expectations and that’s bad. That means I agree we should do something here, but the right answer might take a bit of time to happen.

There is no hurry, thanks for all your explanations and sorry to not be able to help on this, my knowledge about all this is limited.

For now, I’d request setting TERM to something that makes ripgrep work as a temporary work-around. Hopefully that’s feasible to do.

Ok, we will use TERM=eterm-color as a workaround for now.

Thanks again for your help on this.

Thierry

thierryvolpiatto on Oct 15, 2016

@thierryvolpiatto @xuchunyang I think the bottom line here is that while ripgrep is technically respecting the letter of the law, it doesn’t actually match up with user expectations and that’s bad. That means I agree we should do something here, but the right answer might take a bit of time to happen. For now, I’d request setting TERM to something that makes ripgrep work as a temporary work-around. Hopefully that’s feasible to do.

BurntSushi on Oct 15, 2016

At least GNU grep hard codes ANSI color escape sequences and AFAIK doesn’t actually respect the TERMINFO database. e.g.,

static const char *selected_match_color = "01;31";  /* bold red */

ripgrep isn’t failing as far as I can see, it’s simply respecting what the environment is saying, while all of the other tools aren’t.

What is the correct behavior here? If TERM=dumb is set and --color=always is set, then how does ripgrep know which TERM settings to use? Should it forcefully pick a TERM other than dumb? Which one?

BurntSushi on Oct 15, 2016