Using style "bold" does not use the bold ansi escape sequence in the output #293
Comments
|
Hmm, yes, I think this might be related to #266 (possibly even a dupe).
This sounds like a really bad idea. It would be better to not rely on colors to parse the output. My guess is that the right fix for that is #244, but I don't know for sure because I don't know what problem you're trying to solve. |
I agree, but it might be a 31-year-old code base. ;-) And the design will probably not change because it's targeting GNU grep (which does not offer another output format to my knowledge). I see these issues discussed in #244 as well. I will also look into the other issues discussing editor integration. Thanks. |
|
@ilohmar Unfortunately, it can't be a goal of ripgrep to be completely interface compatible with GNU grep (or any other grep) since it takes a fundamentally different view on how searching works by default. So you already need to be able to tweak the CLI invocation itself, and at that point, it seems like it's not unreasonable to expect to parse the output specially too. With that said, I can understand how using the color codes as a common interface would be tempting. I expect that in practice, once we nail out these last color issues, that stuff won't change going forward. |
Previously, ripgrep would only emit the 'bold' ANSI escape sequence if
no foreground or background color was set. Instead, it would convert colors
to their "intense" versions if bold was set. The intent was to do the same
thing on Windows and Unix. However, this had a few negative side effects:
1. Omitting the 'bold' ANSI escape when 'bold' was set is surprising.
2. Intense colors can look quite bad and be hard to read.
To fix this, we introduce a new setting called 'intense' in the --colors
flag, and thread that down through to the public API of the `termcolor`
crate. The 'intense' setting has environment specific behavior:
1. In ANSI mode, it will convert the selected color to its "intense"
variant.
2. In the Windows console, it will make the text "intense."
There is no longer any "smart" handling of the 'bold' style. The 'bold'
ANSI escape is always emitted when it is selected. In the Windows
console, the 'bold' setting now has no effect. Note that this is a
breaking change.
Fixes #266, #293
|
Fixed in b187c1a |
As @BurntSushi described in #51, color customization with the style "bold" is interpreted as "use a high-intensity color", therefore (when using a terminal) the actual ANSI escape sequence for bold text never appears in the output.
It would be great if this were an optional translation, such that "bold" really meant "output bold ANSI sequence" by default.
This is especially important when the output is parsed by a 3rd party that expects the color customization to work this way (as it does, e.g., for
git grepor GNUgrep).The text was updated successfully, but these errors were encountered: