This will be needed to later support zero-copy deserialization of independent
syntax sets, but is interesting and useful on its own.
Instead of deferring serialization and deserialization to syntect, we implement it
ourselves in the same way, but make compression optional.
We can't use #[from] on Error::Msg(String) because String does not implement Error.
(Which it shouldn't; see e.g. https://internals.rust-lang.org/t/impl-error-for-string/8881.)
So we implement From manually for Error::Msg, since our current code was written
in that way for error-chain.
Move code to build assets to its own file. That results in better modularity and flexibility.
It also allows us to simplify HighlightingAssets a lot, since it will now always
be initialized with a SerializedSyntaxSet.
The v0.18.3 release was a hotfix release to make bat build again with Rust 1.54.
This merge commit brings in all changes from the hotfix release into the master
branch.
In practice, this only brings in one new commit, namely b146958ec. The other
three commits in the release were cherry-picks from master.
Use it like this:
cargo build --no-default-features --features quick-build-application
It reduces dependencies to build from 154 to 125, allowing quicker iteration
when developing the app.
To improve startup performance, we will later load smaller `SyntaxSet`s instead
of one giant one. However, the current API assumes only one `SyntaxSet` is ever used,
and that that implicitly is the `SyntaxSet` from which returned `SyntaxReference`s
comes.
This change changes the API to reflect that `SyntaxSet` and `SyntaxReference`
are tightly coupled, and enables the use of several `SyntaxSet`.
Instead of 100 ms - 50 ms, startup takes 10 ms - 5 ms.
HighlightingAssets::get_syntax_set() is never called when e.g. piping the bat
output to a file (see Config::loop_through), so by loading the SyntaxSet only
when needed, we radically improve startup time when it is not needed.
They are just a way to get access to data embedded in the binary, so they don't
conceptually belong inside HighlightingAssets.
This has the nice side effect of getting HighlightingAssets::from_cache() and
::from_binary(), that are highly related, next to each other.
Or rather, introduce new versions of these methods and deprecate the old ones.
This is preparation to enable robust and user-friendly support for lazy-loading.
With lazy-loading, we don't know if the SyntaxSet is valid until after we try to
use it, so wherever we try to use it, we need to return a Result. See discussion
about panics in #1747.
Using BufReader makes sense for large files, but assets are never large enough
to require buffering. It is significantly faster to load the file contents in
one go, so let's do that instead.
Closes#1753
It already now reduces code duplication slightly, but will become even more
useful in the future when we add more complicated logic such as lazy-loading.
Since we only modify `pub(crate)` items, the stable bat-as-a-library API is not
affected.
This takes us one step closer to making SyntaxSet lazy-loaded, which in turn
takes us one step closer to solving #951.
Otherwise Rust 1.53.0 gets confused during `cargo doc` because it thinks
we want an actual URL:
warning: this URL is not a hyperlink
--> src/pretty_printer.rs:331:40
|
331 | /// The title for the input (e.g. "http://example.com/example.txt")
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use an automatic link instead: `<http://example.com/example.txt>`
|
= note: `#[warn(rustdoc::bare_urls)]` on by default
= note: bare URLs are not automatically turned into clickable links
It was perhaps also a bit confusing to give an URL as an example in the
first place, because according to our own API example
`examples/inputs.rs` it is meant to be more a free-text thing.
Without this change, creating a PR triggers all jobs to run twice. Once
due to a push event and once due to a pull_request event.
Change to only trigger jobs due to push when pushing a tag or to the
master branch, to avoid duplicate jobs for each PR.
As discussed in #1519, the batcat snap package is too problematic for
official endorsement, so withdraw recommendation from README.me (and
remove section from CHANGELOG.md since a release with it has not been
made yet).
Fixed by implementing the proposal by sharkdp:
* Allow PAGER=bat, but ignore the setting in bat and simply default to
less. Unless of course, BAT_PAGER or --pager is used to overwrite the
value of PAGER.
* Disallow the usage of bat within BAT_PAGER and --pager.
Since we run clippy on Rust 1.42.0 we still get warnings about the
presence of clippy::match_bool lints. That lint has been moved from
'Style' to 'Pedantic' in Rust 1.45.0 and onwards however, so let's
silent it in our clippy runs too.
All bat tags begin with a small 'v', so no need for a generic pattern in
the CI script. This will also help us ensure we keep the same format on
future tags.
Not only when a release tag is pushed. Also publish these Debian
packages as artifacts. This makes PR workflows more similar to release
work flows, and reduces risk of build system regressions that we don't
detect until we make a new release.
For #1474
This enables us to later always build Debian packages. If you try to use
a git sha as Debian package version you will get an error:
dpkg-deb: error: parsing file '_staging/dpkg/DEBIAN/control' near line 2 package 'bat':
error in 'Version' field string 'd2963ce4': version number does not start with digit
so we need to use a version that is always available.
We duplicate the bat version in another place here which is a bit bad,
but it is already duplicated a lot, so we don't make things
significantly worse. It is still kind of nice to not have to figure out
a good and robust way to parse out the version from Cargo.toml in the CI
script.
For #1474
The end goal is to upload the same artifacts for a PR as we deploy
during a release, to make a regular PR pipeline as similar as possible
to a deploy.
The first step is to move 'Upload build artifacts' to after 'Package' so
we can upload the same files. Also change the name and artifacts to be
more similar to what we deploy for a release.
For #1474
This results in a nicer workflow file that is easier to follow.
Also remove the unneccesary doc row that repeats what is already in the
matrix and that is annoying to keep up to date.
For #1474
There is no usage of `steps.vars.outputs.REF_*` so no need to setup such
things. Also remove setting up REF_NAME and REF_BRANCH env vars, since
they are never read.
because we always use "stable". If we need to go back to using
matrix.job.toolchain, we should do it like in jobs.coverage, instead of
messing about with vars and outputs.
Martin Nordholts