Most existing builtins are removed but not yet ported, so the test
`user_can_override_builtin_mappings` should fail. It should pass once the old
rules have been ported.
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.
There is now support for a systemwide config file. The location of the
system wide config file is `$(BAT_SYSTEM_CONFIG_PREFIX)/bat/config`.
`$(BAT_SYSTEM_CONFIG_PREFIX)` has to be provided at compile time as an
environment variable. If the environment variable is not set, a default
is used. This default is `C:\ProgramData` for windows and `/etc` for
every other os.
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.
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.
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`.
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.