The NO_COLOR convention (https://no-color.org) only calls for
suppressing ANSI *color* codes. It does not demand the removal of
other attributes such as bold, italic, underline or reverse.
Previously, Paint::is_enabled() bundled anstyle_query::no_color()
into the single boolean that decides whether to emit any formatting.
Because Paint relies on that boolean alone, NO_COLOR ended up
stripping bold, italic, reverse, etc. alongside the color codes.
That conflates two concerns: terminal styling support and color
suppression. It is also contrary to the intent of the standard.
Instead, treat the general style decision separately from the
color decision. Remove the no_color() check from is_enabled()
and add Paint::is_styling_enabled() for the coarse terminal gate.
Style::fmt_prefix and fmt_suffix now query NO_COLOR directly and
conditionally drop foreground and background codes while preserving
non-colour properties. This way bold, italic, underline and the
like continue to work when NO_COLOR is set, while colors alone are
suppressed.
Closes: rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5/cob/xyz.radicle.issue/f922d90
Assisted-by: Pi:deepinfra/moonshotai/Kimi-K2.6
Signed-off-by: Richard Levitte <richard@levitte.org>
The `.envrc` file acts as a personal setup file, and should not be checked in.
The team provides `.envrc.sample` where contributors can choose to:
echo 'source_env .envrc.sample' >> .envrc
To bootstrap their own `.envrc` file.
Two tests assumed that `refs/remotes/rad/HEAD` would automatically be
crated. It turns out, however, that this only the case if executed
with Git 2.48.0 or newer. Git versions older than 2.48.0 do not touch
'refs/remotes/<remote>/HEAD'.
Git 2.48.0 and newer will update `refs/remotes/<remote>/HEAD` by
default. This can be disabled by setting
`remote.<remote>.followRemoteHEAD` to "never". Thus, with these
versions, setting that configuration to "never" emulates the behaviour
of older versions.
Therefore, to ensure that test results are consistent across Git
versions before and after 2.48.0, the fixture of test repositories
now include setting 'remote.rad.followRemoteHEAD = never'.
The affected tests are adjusted accordingly.
This change can possibly be reverted once Radicle requires usage of Git
2.48.0 or newer.
Co-authored-by: Lorenz Leutgeb <lorenz.leutgeb@radicle.xyz>
Do it by setting the environment variable 'CARGO_CMD' when running
'just', or by overriding the justfile variable 'cargo_cmd', like so:
CARGO_CMD='cargo --locked' just ...
or:
just cargo_cmd='cargo --locked' ...
`radicle-cli-test` initiates `cargo` builds under the assumption
that the target directory is always within the source directory.
However, the user may have a different idea, specified with the
environment variable `CARGO_TARGET_DIR` (supported by `cargo`, see
https://doc.rust-lang.org/cargo/reference/environment-variables.html).
Add support for `CARGO_TARGET_DIR`, with a fallback to 'target'
at the top of the source tree if `CARGO_TARGET_DIR` is undefined.
Each revision now shows a `{base}..{head}` range instead of just the
head. This is meant to clarify when a patch is rebased, and to be
helpful when one might want to observe changes using 'git range-diff'.
This adds `conflicts_with` for `private` and `public` to simplify the logic that checks for the document visibility
(thank you Fintan)
Co-authored-by: Fintan Halpenny <fintan.halpenny@gmail.com>
This gives the possibility to see the inventory of another node than self.
This does replicatee the functionality of 'rad node routing --nid', but
feels like a more intuitive command to try.
In the 'clone' command, a 'signer' is instanciated just to get the
public key. In the 'job' command, a 'signer' is instanciated early,
even when the subcommand doesn't use it.
That's unnecessary, and infers the potential use of RAD_PASSPHRASE.
In those cases, avoid instanciating a 'signer'.
Richard Levitte