We need to bump 0.x.0 because the library API changed in incompatible
ways:
$ cargo public-api diff
Resolved `diff` to `diff 0.23.0`
Removed items from the public API
=================================
(none)
Changed items in the public API
===============================
-pub fn bat::controller::Controller<'b>::run(&self, inputs: alloc::vec::Vec<bat::input::Input<'_>>) -> bat::error::Result<bool>
+pub fn bat::controller::Controller<'b>::run(&self, inputs: alloc::vec::Vec<bat::input::Input<'_>>, output_buffer: core::option::Option<&mut dyn core::fmt::Write>) -> bat::error::Result<bool>
-pub fn bat::controller::Controller<'b>::run_with_error_handler(&self, inputs: alloc::vec::Vec<bat::input::Input<'_>>, handle_error: impl core::ops::function::Fn(&bat::error::Error, &mut dyn std::io::Write)) -> bat::error::Result<bool>
+pub fn bat::controller::Controller<'b>::run_with_error_handler(&self, inputs: alloc::vec::Vec<bat::input::Input<'_>>, output_buffer: core::option::Option<&mut dyn core::fmt::Write>, handle_error: impl core::ops::function::Fn(&bat::error::Error, &mut dyn std::io::Write)) -> bat::error::Result<bool>
Added items to the public API
=============================
[...]
This opens up future possibilities:
* GitHub's auto-merge feature that merges a PR once CI passes
* Auto-merge of dependabot PRs that pass CI
But before we do any of that we need to have this new job active for a
while to see that it works.
Without fix:
$ cargo +nightly build
Compiling proc-macro2 v1.0.54
error[E0635]: unknown feature `proc_macro_span_shrink`
--> /home/martin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.54/src/lib.rs:92:30
|
92 | feature(proc_macro_span, proc_macro_span_shrink)
| ^^^^^^^^^^^^^^^^^^^^^^
For more information about this error, try `rustc --explain E0635`.
error: could not compile `proc-macro2` (lib) due to previous error
This CI check will fail if there are crates with known security vulnerabilities in Cargo.lock.
It will not fail because of warnings. We currently have two warnings.
Note that cargo-audit is installed by default on GitHub's Ubuntu
runners.
From now on, any changes to the help texts will be visible in PR diffs,
which will make it very easy to review, and very hard to accidentally
miss changes to help texts.
If a contributor makes a change to help texts, the `cargo test` failure
text they will see contains instructions on how to update the blessed
help texts:
error: expect test failed
--> ../doc/long-help.txt
You can update all `expect!` tests by running:
env UPDATE_EXPECT=1 cargo test
In short, to update blessed help texts, one simply does
env UPDATE_EXPECT=1 cargo test
Do not run the tests if the `git` feature is missing, since then
`--diff` will be missing from `--help`. And do not run the tests on
Windows, because then the help text will contain the term `.exe`.
Move man page step to after cargo doc step so that the man page exists
when we look for it.
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.
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.
* Make the default macOS theme depend on Dark Mode
We frequently get complaints from macOS users that bat does not work on
their default macOS terminal background, which is white.
Pay the price of slightly increased startup time to get a better default
on macOS. To avoid the slightly increased startup time, simply specify a
theme explicitly via `--theme`, `BAT_THEME`, or `~/.config/bat`.
Note that if there is an error when we check if Dark Mode is enabled, we
behave the same as on Windows and Linux; assume that the terminal
background is dark. This harmonizes behavior across platforms, and makes
bat behave the same as before, when Dark Mode was always assumed to be
enabled.
* src/assets.rs: Fix typo
* Update CHANGELOG.md
We need to type `inf` and `INF` as strings in `INI.sublime-syntax`,
otherwise `yaml-rust` interprets them as real numbers ("infinity") and
they do not get registered as file extensions:
/Users/martin/src/yaml-rust # https://github.com/chyh1990/yaml-rust
% cargo run --example dump_yaml ~/src/bat/assets/syntaxes/02_Extra/INI.sublime-syntax
---
String("name"):
String("INI")
String("file_extensions"):
String("ini")
String("INI")
Real("inf")
Real("INF")
...
Also add a regression test.
* Simplify release-checklist.md by printing `-h`, `--help` and `man` in CI
Note that we run `find . -name bat.1` before we run anything with
`--all-features`, because `--all-features` is considered a separate
target, and so we will get a different (but identical) `bat.1`. For
example, we might have these:
./target/debug/build/bat-218e9538b4996215/out/assets/manual/bat.1
./target/debug/build/bat-89d6f56802af023f/out/assets/manual/bat.1
By showing the man page earlier, there is only one `bat.1` to pick from.
* Use plain `man $(find . -name bat.1)`
We do this to only have one invocation of `highlighter.highlight(...)`
so we don't need to change to `highlighter.highlight_line(...)` in two
places in #2181.
Clippy in the newly released Rust 1.60 found some new lints.
Conveniently, all of them were fixable with `--fix`.
By fixing these lints it becomes easier for us and others to see when
new lints are introduced.
* CONTRIBUTING.md: Encourage regression tests
* Add colon before listing pros of regression tests
Co-authored-by: Keith Hall <keith-hall@users.noreply.github.com>
I am setting up a new computer and thus are missing a lot of tools. I
noticed we rely on `jq` being installed, which is a bit annoying when it
is not installed yet.
We can quite easily get rid of this dependecy on `jq` by using a simple
`python3` oneliner.
The text that is printed is generated when building assets, by analyzing LICENSE
and NOTICE files that comes with syntaxes and themes.
We take this opportunity to also add a NOTICE file as defined by Apache License 2.0.
Using Markdown for a startup test is useful since it has so many dependencies on
other syntaxes. So such a test makes sure that lazy-loading of syntaxes work.
It is however also useful to measure the startup time of bat when the time to
load a syntax is very small, and the measured startup time has mostly non-syntax
related causes. Such as:
* Parsing arguments
* Setting up syntax mapping
* Loading themes
This commit adds such a test. It uses the CpuInfo syntax which is very small.
Only 14 lines, compared to the 1581 lines that Markdown is (not including the
size of its included syntaxes).
This command can be used to get an approximation of the size of syntaxes, and
thus how expensive they are to load:
find -name *.sublime-syntax -print0 | xargs --null wc -l | sort -n -r
We started to use lazycell because syntect already used it. But syntect has
changed to use once_cell. So we should also do that to prepare for using the
upcoming version of syntect.
I had to use a `lazy_static` due to that the clap API that only accepts a
reference to a version string. And, in our code, only a 'static reference to a
version string.
Code could probably be refactored to accept a "normal" reference, but that would
be a major undertaking.
The file `LiveScript.sublime-syntax` is a pure export from a licenced version
of Sublime Text, Version 3.1.1, Build 3176 with
assets/syntaxes/02_Extra/LiveScript/Syntaxes/LiveScript.tmLanguage as the source
file.
* syntax-tests: Make CpuInfo test actually work
File extension matching is case-sensitive, so extension needs to be .cpuinfo for
the syntax to actually be used.
* Also fix MemInfo
Mainly to make it easier to see what went wrong when it fails.
If this ever gets of out sync with a particular Rust version, we can most likely
save the situation by introducing a `rustfmt.toml` file.
By forwarding the task to find the `Plain Text` syntax to `assets`. Not only does
the code become simpler; we also get rid of a call to `self.get_syntax_set()`
which is beneficial to the long term goal of replacing `syntaxes.bin` with
`minimal_syntaxes.bin`.
Note that the use of `.expect()` is not a regression in error handling. It was
previously hidden in `.find_syntax_plain_text()`.
This information is useful when you want to build several SyntaxSets, but
without having to duplicate SyntaxDefinitions. For example:
"Rust" has no dependencies. But "Markdown" depends on "Rust". With the data
structures this code adds, we know that "Rust" is a dependent syntax for
"Markdown", and can construct a SyntaxSet that takes that into account.
Note that code has a temporary environment flag to ignore any information about
dependents when constructing SyntaxSets. Code that makes use of the new data
structure will be added later.
Martin Nordholts