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.
This will fix#614 by making it clear what is wrong by showing the
following error message:
Failed to load one or more themes from
'/Users/me/.config/bat/themes' (reason: 'Invalid syntax theme
settings')
We also need to add a check if theme_dir.exists(), otherwise an absent
dir will seem like an error:
Failed to load one or more themes from
'/Users/me/.config/bat/themes' (reason: 'IO error for
operation on /Users/me/.config/bat/themes: No such file or
directory (os error 2)')
(This is the same check we already have for syntax_dir.)
This macro is intended to be package-internal and is not to be
considered part of the public lib API.
Use it in three places to reduce code duplication. However, main reason
for this refactoring is to allow us to fix#1063 without duplicating the
code yet another time.
The macro can also be used for the "Binary content from {} will not be
printed to the terminal" message if that message starts to use eprintln!
instead (if ever).
To trigger/verify the changed code, the following commands can be used:
cargo run -- --theme=ansi-light tests/examples/single-line.txt
cargo run -- --theme=does-not-exist tests/examples/single-line.txt
cargo run -- --style=grid,rule tests/examples/single-line.txt
This combines ansi-light and ansi-dark into a single theme that works
with both light and dark backgrounds. Instead of specifying white/black,
the ansi theme uses the terminal's default foreground/background color
by setting alpha=01, i.e. #00000001. This is in addition to the alpha=00
encoding where red contains an ANSI color palette number.
Now, `--theme ansi-light` and `--theme ansi-dark` will print a
deprecation notice and use ansi instead (unless the user has a custom
theme named ansi-light or ansi-dark, which would take precedence).
When saving/reading user-provided syntaxes or themes, `bat` will now maintain a
`metadata.yaml` file which includes information about the `bat` version which was
used to create the cached files. When loading cached files, we now print an error
if they have been created with an incompatible version
closes#882
