Module conciliator::style
source · Expand description
§Customization
The color Palette
and decorative Tags
used by the Conciliator
can be customized at compile-time through environment variables. CONCILIATOR_PALETTE
and CONCILIATOR_TAGS
will be parsed by const
functions to determine the default palette and tags.
§Custom Palette
The CONCILIATOR_PALETTE
environment variable can be set to override the default Palette
.
It should contain the names of all 8 ColorCode
s you want to use, separated by a comma and a space (,
).
The order is the same as the fields in the Palette
struct: the color of the [ ]
brackets, then Alpha, Beta, Gamma, Delta, Zeta, Iota and Omega.
Note that the capitalization has to match the ColorCode
exactly: IntenseBlue
& Red
will work, intenseblue
, intense_blue
, red
, RED
and so on will not.
Alternatively, you can use the numeric representation of the ColorCode
, which is an integer from 0 to 15 (inclusive).
See the ColorCode
documentation for a table of all colors and their associated numbers.
[env]
# default color palette
CONCILIATOR_PALETTE = "White, Blue, Green, IntenseCyan, Cyan, Yellow, Red, IntenseBlack";
# same color palette using numeric representation
CONCILIATOR_PALETTE = "7, 4, 2, 14, 6, 3, 1, 8";
§Custom Tags
As described in the Conciliator
docs, the [ > ]
tags are purely decorative.
Additionally, glyphs may look completely different depending on the terminal font that is used, or may not be available at all.
Because of this, and because everyone has different tastes, the characters / strings that are used can be customized.
By default, the Tags
use only basic characters (>
, +
and letters) that should be available in all terminal fonts.
This is a very conservative choice for maximum compatibility out-of-the-box, which you are welcome to override by setting the CONCILIATOR_TAGS
environment variable at compile-time.
The CONCILIATOR_TAGS
environment variable needs to contain all the tags (status, info, warn & error) in comma-separated (,
) square brackets ([ … ]
).
Additionally, it needs to begin with [ Tags ],
like in the two examples given below.
[env]
# default tags, should be compatible with all terminal fonts
CONCILIATOR_TAGS = "[ Tags ], [ > ], [ + ], [ WARN ], [ ERROR ]"
# prettier status & info tags using glyphs that may not be available
CONCILIATOR_TAGS = "[ Tags ], [ ➤ ], [ → ], [ WARN ], [ ERROR ]"
§Environment Variables
There are many ways to set these environment variable during your build, but the recommended way is to use the [env]
section of .cargo/config.toml
configuration files for Cargo.
As you can read in the Cargo book, this offers a lot of flexibility: you can place these configuration files in the crate, workspace, or even under the home directory. Unfortunately, the precedence of these files is not quite what we would want here, since the user’s personal configuration in their home directory gets overruled by anything set at the crate and workspace level.
On top of that, Cargo might fail to recompile the dependency when you change the environment variables (possibly related to cargo#13280).
If this happens to you, you can run cargo clean -p conciliator
in your crate/workspace directory to force it to recompile the dependency in the next cargo build
.
Please note that there are currently no error messages if the CONCILIATOR_TAGS
or CONCILIATOR_PALETTE
strings are invalid.
If the tags or palette can’t be parsed, it will just silently fall back to the default.
Finally, remember that the environment variables will only be read and parsed at compile-time.
Structs§
- Provides a simplified and unified set of
ColorCode
s, i.e. a color palette - Stores the strings used as tags by the
Conciliator
Enums§
- Color in the color
Palette
Traits§
- Extends
EmitEscapes
to easily push (colored) text onto a buffer