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.
Right now all tests pass even if we e.g. return
Ok(OutputType::stdout())
instead of doing
.chain_err(|| "Could not parse pager command.")?
so add a test to make sure this functionality don't break.
Turns out GitHub is clever enough to pick up clippy warnings from us
just running it, and showing them in PRs under a "Unchanged files with
check annotations (beta)" header.
The only warnings currently shown are style warnings, and we agreed we
don't want to risk putting off contributors over style issues. So
explicitly allow (don't warn in the logs for) this category of clippy
lints.
This means that the only clippy categories left that prints warnings
(Warn) are:
clippy::complexity
clippy::perf
And the only category of lints that fails the CI build (Deny) remains to
be:
clippy::correctness
See https://rust-lang.github.io/rust-clippy/master/index.html for a
catalog of all lints.
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.)
To trigger/verify the changed code, run
bat --list-languages # or -L
This is the last clippy warning in the code that you get if you run
cargo clippy --all-targets --all-features -- --allow clippy::style
so by fixing it it becomes easier to spot when a new warning is
introduced (that does not belong to the clippy category clippy::style).
And by making it easy to spot new warnings, we increase chance of such
regressions not ending up in the code base.
Only the 'correctness' category of lints are 'deny' by default. This is
the only clippy lints we want to enforce for now. The other ones we just
want to print in the logs. So remove any --deny and --allow arguments.
See discussion in #1410.
Run the linter on the minimum supported rust version; otherwise we will
get lint warnings for things that require a too high Rust toolchain
version to fix.
Allow the following checks, since we already violate them our code:
- clippy::new-without-default
- clippy::match-bool
- clippy::if_same_then_else
Eventually we should fix these lint issues and then disallow them to
prevent them from coming back in other places.
The clippy args used is recommended here:
https://github.com/rust-lang/rust-clippy#travis-ci
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 is a regression test for the fix for issue #299. If that fix is
reverted, currently only one test ('header_padding') fails. But that
test is for a different use case, so add a dedicated regression test for
the particular use case issue #299 is about.
The macOS version of mktemp does not recognize the --suffix option.
Using pure -d should work since, it seems [1], macOS 10.11 however.
So to make the script work on macOS, stop using the --suffix option.
The downside is of course that the temporary dir will have an anonymous
name, but I see no risk of confusion given how short-lived the usage of
the dir is, and given the context it is used.
[1] https://unix.stackexchange.com/questions/30091/fix-or-alternative-for-mktemp-in-os-x
This fixes#1438.
Note however, that using a pager such as less will add a newline itself.
So to actually not print a newline for such files, you need to either
disable paging:
bat --style=plain --paging=never no-newline-at-end-of-file.txt
or use a "pager" that does not add a newline:
bat --style=plain --pager=cat no-newline-at-end-of-file.txt
Note that we also update syntax tests file since a bunch of them had
missing newlines on the last lines.
Since it has a functional role, we can not just replace it, we must keep
it around. This also allows us to simplify the code slightly.
We must fix this before we fix#1438 since otherwise the \n will be
missing with --style=plain, since we will stop adding it if it is
missing.
Martin Nordholts