Fix Clippy lints

[mohamed-abdelnour]

The Minimum Supported Rust Version (MSRV) for bat is 1.45.0. Setting msrv = "1.45.0" in .clippy.toml (not part of the repository) and running cargo clippy emits 7 warnings. These are proposed fixes to said warnings. If there are any lints we would rather allow, I can revert the relevant commit(s) and add the appropriate lint attribute(s).

Also, do you think we should create .clippy.toml/clippy.toml and set the MSRV to ensure consistency amongst contributors?

[mohamed-abdelnour]

Forgot to ask, do I update the CHANGELOG for something like this? If so, does it go under the "Other" heading?

[Enselic]

Thanks for taking the time to make another contribution!

Seems like we can't add msrv in .clippy.toml to the repo, because it was introduced in Rust 1.50.0 (commit) and will cause an error with Rust 1.45.0:

% cargo clippy         
    Checking bat v0.18.1 (/home/martin/src/bat)
error: error reading Clippy's configuration file `/home/martin/src/bat/.clippy.toml`: unknown field `msrv`, expected one of ...

error: aborting due to previous error

error: could not compile `bat`.

To learn more, run the command again with --verbose.

I suspect that latest Rust clippy is smarter than in 1.45.0 and therefore finds more lints.

I took a quick look at your changes, and they all seemed reasonable, but I need some more time to make an in-depth code review.

I personally think it is fine to mention this in CHANGELOG.md under Other.

[mohamed-abdelnour]

Thank you for your review!

Seems like we can't add .clippy.toml to the repo, because it was introduced in Rust 1.50.0 (commit) and will cause a compilation error with Rust 1.45.0:

Got it, maybe in the future when the MSRV is bumped to 1.50.0.

I took a quick look at your changes, and they all seemed reasonable, but I need some more time to make an in-depth code review.

Take all the time you need!

Given that the lints are not showing up on 1.45.0, as a point of reference, I'll post links to the lints and their relevant commit(s). Hopefully this helps with the review process. Links are in the format:

• Clippy lint
  • Relevant commit(s)

Clippy Lints

• comparison_to_empty
  • mohamed-abdelnour/bat@49e383d014867665d63cbdc5eb3a7fcc486c156b
• match_like_matches_macro
  • mohamed-abdelnour/bat@c42382949e41852f875bbd2e5ba15e1516dc9b42
• field_reassign_with_default
  • mohamed-abdelnour/bat@8dd7f4c50f3f1895729e63358e0a2ffc099788e0
  • mohamed-abdelnour/bat@37593bac222992052b82bb3fc6194f8f66997d87
• from_over_into
  • mohamed-abdelnour/bat@b80d53322f4e546aabed6efbe0831d07fab3ab5a

[sharkdp]

I personally think this is quite a bit harder to read now. The previous match isn't great either. Maybe this should be written with an outer if clause instead?

let use_less_instead = if source == PagerSource::EnvVarPager {
  // full comment here
  matches!(&kind, PagerKind::More | PagerKind::Most | …)
} else {
  false
};

[sharkdp]

The other changes look good - thank you!

[mohamed-abdelnour]

Thank you!

Maybe this should be written with an outer if clause instead?

I agree, this is much better.

matches!(&kind, PagerKind::More | PagerKind::Most | …)

Just checking, kind does not need to be referenced here, given that we're not creating a tuple anymore and it would be automatically dereferenced after rust-lang/rfcs#2005, correct?

[mohamed-abdelnour]

On another note, I promise I'm not trying to rush you or anything, I am just new here and wanted to know what is more convenient for you. I was working on another issue and wanted to discuss it so I added a couple of comments to the issue; is that easy for you to spot and review, or should I create a PR and have the discussion there?

[sharkdp]

Just checking, kind does not need to be referenced here, given that we're not creating a tuple anymore and it would be automatically dereferenced after rust-lang/rfcs#2005, correct?

Right. Didn't test my code :-)

On another note, I promise I'm not trying to rush you or anything, I am just new here and wanted to know what is more convenient for you. I was working on another issue and wanted to discuss it so I added a couple of comments to the issue; is that easy for you to spot and review, or should I create a PR and have the discussion there?

No. Discussion in the ticket is completely fine. Comments should be visible to everyone watching the repo. We just didn't have the time to answer, yet.

[mohamed-abdelnour]

No. Discussion in the ticket is completely fine. Comments should be visible to everyone watching the repo. We just didn't have the time to answer, yet.

Got it, take as much time as you need! Thank you for being patient will all my questions; I appreciate it! :)