The intention is to take advantage of `std::io::IsTerminal` that landed
in 1.70.0, both in `bat` and its dependencies (`clap`, `grep-cli`).
This will fix#2570 as well - `grep-cli` 0.1.9 has a patch for that.
Signed-off-by: mataha <mataha@users.noreply.github.com>
The `dirs` crate was forked as `dirs-next` after the original repos were archived.
The fork hasn't released a new version since October 2020, while the original
has been taken off the shelf and has seen updates since then.
This reverts commit 8174e02279. Turns out
it is needed for a common use case, see
https://github.com/sharkdp/bat/issues/2307.
It is not a clean revert, because I adjust CHANGELOG.md and also add a
comment to the test. I also had to resolve a small `use` conflict.
* Strip BOM from output in interactive mode
* Strip BOM when not loop_through, add regression tests
* Update CHANGELOG.md
* Only strip BOM from beginning of first line
* Fix integration test on macOS that relied on color scheme
* Fix integration test on Windows that relied on detected terminal width
* Fix syntax test that was failing due to a previously wrong (now fixed) highlighting
Co-authored-by: David Peter <mail@david-peter.de>
Co-authored-by: Martin Nordholts <enselic@gmail.com>
Ths does remove the specialization of version's description. The way
this is done (internally through `mut_arg`) doesn't play well with
subcommands. Clap tries to force this version of `version` into the
subcommand despite not being needed. Clap v4 dramatically changes how
version customization works.
clap also does more error checks now to prevent programmer mistake, so
we can't have a conflict with an argument that is conditionally there,
so I swapped the condition.
We can't keep `syntect::parsing::SyntaxReference` as part of the public
API, because that might prevent us from bumping to syntect 6.0.0 without
also bumping bat to v2.0.0, once we reach v1.0.0.
So introduce a new stripped down struct `Syntax` and return that
instead. Let it be fully owned to make the API simple. It is not going
to be in a hot code path anyway.
I have looked at all code of our 27 dependents but I can't find a single
instance of this method being used, so this change should be safe for
v1.0.0.
