Closed ericfreese closed 5 years ago
The implementation is not a problem, this is all handled by the termcolor crate.
Note that all color options will not work (or have the same effect) on all OSs, and I would like to keep the default configuration to be something that works everywhere (in particular on Windows).
The main issue I see is what command line arguments to provide. What do other unix tools do? Let's try to find a good enough design: few arguments, readable color syntax, possibility to handle all kinds of attributes supported on console APIs.
For reference: https://docs.rs/termcolor/1.0.5/src/termcolor/lib.rs.html#1413-1419
What would you think of a config file in $XDG_CONFIG_HOME
? It could be a simple key value pair where the key specifies the thing to be styled and the value specifies the style for it. Could have an alternate API as well where those keys/values are provided/overriden by either environment variables or arguments.
Could possibly use git for inspiration? See the color
section under https://manpages.debian.org/jessie-backports/git-man/git-config.1.en.html#Values
The value for a variable that takes a color is a list of colors (at most two, one for foreground and one for background) and attributes (as many as you want), separated by spaces. The basic colors accepted are normal, black, red, green, yellow, blue, magenta, cyan and white. The first color given is the foreground; the second is the background. Colors may also be given as numbers between 0 and 255; these use ANSI 256-color mode (but note that not all terminals may support this). If your terminal supports it, you may also specify 24-bit RGB values as hex, like #ff0ab3. The accepted attributes are bold, dim, ul, blink, reverse, italic, and strike (for crossed-out or "strikethrough" letters). The position of any attributes with respect to the colors (before, after, or in between), doesn’t matter. Specific attributes may be turned off by prefixing them with no or no- (e.g., noreverse, no-ul, etc). For git’s pre-defined color slots, the attributes are meant to be reset at the beginning of each item in the colored output. So setting color.decorate.branch to black will paint that branch name in a plain black, even if the previous thing on the same output line (e.g. opening parenthesis before the list of branch names in log --decorate output) is set to be painted with bold or some other attribute. However, custom log formats may do more complicated and layered coloring, and the negated forms may be useful there.
What would you think of a config file in
$XDG_CONFIG_HOME
? It could be a simple key value pair where the key specifies the thing to be styled and the value specifies the style for it. Could have an alternate API as well where those keys/values are provided/overriden by either environment variables or arguments.Could possibly use git for inspiration? See the
color
section under https://manpages.debian.org/jessie-backports/git-man/git-config.1.en.html#Values
Thanks for the input! I will take a look at how some projects provide that info among other unix tools, but that spec is quite attractive. Another alternative would be ripgrep format.
I was more thinking about process flags with arguments rather than (yet another) config file
.gitconfig
is ok, it is a once-only thing)And a config file can still be added later.
Flags work for me too. They can always be encapsulated in a shell alias/function :+1:
merged #9. This should allow users to configure the tool output as they like.
Thanks @mookid :tada:
Not sure how this would be best implemented, but it would be nice to be able to specify different colors/highlighting styles.