Add mounted filesystem info

[daviessm]

From ogham/exa#941

In grid view underlines directories which have filesystems mounted on them.

In long view displays the mounted filesystem and type.

Couple of questions:

• I'm happy with the underline for denoting a mounted fs, but the long format looks a bit weird. Does anyone have better suggestions how to format it?
• Should the long view details be enabled by an option?

The original exa PR also had a btrfs subvolume feature but I'll implement that on top of this one once accepted. Same two questions will go for that one as well.

[daviessm]

Added option -M/--mounts which enables the display of the extra information on long and tree views, plus associated documentation and shell completions.

[cafkafk]

The commit summaries should follow conventional commits, see https://github.com/eza-community/eza/pull/149/files for a summary of what is expected.

[daviessm]

@cafkafk thanks, I've squashed the commits. Things I'm missing at the moment are:

• Tests
• EXA_COLORS in ui_styles.rs

I'm unsure how to do tests. I can see that there are some tests for options in https://github.com/daviessm/eza/blob/deb429e5cc412d49914133e457519ab9377b1a44/src/options/view.rs#L555 but I don't understand how they work and whether there's anywhere else that needs them.

For EXA_COLORS do I need to make up a new code "mp" for mount point and add it to ui_styles.rs and eza_colors.5.md?

[cafkafk]

For EXA_COLORS do I need to make up a new code "mp" for mount point and add it to ui_styles.rs and eza_colors.5.md?

I haven't really touched this part of the code yet, but yea, that would be nice to have.

but I don't understand how they work and whether there's anywhere else that needs them.

Neither do I tbh, the situation with testing is still very shaky at best. I wish I could provide more guidance on this, but we still need a good solution for integration testing. Until then, if you can understand more about view.rs tests and see if they would be useful then that would be a appreciated.

I honestly struggle to see if there is any obvious way to write any unit tests for this PR... so it's probably not necessary/feasible.

[daviessm]

but I don't understand how they work and whether there's anywhere else that needs them.

Neither do I tbh, the situation with testing is still very shaky at best. I wish I could provide more guidance on this, but we still need a good solution for integration testing. Until then, if you can understand more about view.rs tests and see if they would be useful then that would be a appreciated.

I stared at this for ages and still haven't got a clue how it works. Unless anyone understands it we might have to rewrite it (as a new PR, after the serde changes).

I honestly struggle to see if there is any obvious way to write any unit tests for this PR... so it's probably not necessary/feasible.

Short of having a known filesystem to test against in a VM it's not going to be easy. Possibly something for another new PR.

Either way, I don't think there's much more I can do here. PR is ready to merge if you're happy with it.

[cafkafk]

TL;DR: I'd like documentation about the lazy static block. Rest is just what I've checked.

This didn't seem to introduce a performance regression:

Benchmark 1: ./target/release/eza --blocksize -l --hyperlink --grid --git-repos -x --time-style relative  --git --header --icons -Z -@ -o ../
  Time (mean ± σ):      1.649 s ±  0.020 s    [User: 3.011 s, System: 2.236 s]
  Range (min … max):    1.625 s …  1.682 s    10 runs
 
Benchmark 2: eza --blocksize -l --hyperlink --grid --git-repos -x --time-style relative  --git --header --icons -Z -@ -o ../
  Time (mean ± σ):      1.661 s ±  0.034 s    [User: 3.040 s, System: 2.245 s]
  Range (min … max):    1.624 s …  1.719 s    10 runs
 
Summary
  ./target/release/eza --blocksize -l --hyperlink --grid --git-repos -x --time-style relative  --git --header --icons -Z -@ -o ../ ran
    1.01 ± 0.02 times faster than eza --blocksize -l --hyperlink --grid --git-repos -x --time-style relative  --git --header --icons -Z -@ -o ../

The functionality of the UI seems to be as expected, without anything having broken.

This doesn't seem to work for grid view:

It doesn't necessarily need to, but this is a thing to be aware of.

Another note is that this could have been split up into several commits, e.g. documentation changes, completions, man pages could be separate commits. This isn't blocking thou, just a preference for next time.

I didn't test that the env var or completions yet.

EDIT: tested completions for zsh and fish, as well as manual page changes, and they work.

[daviessm]

This doesn't seem to work for grid view:

Yeah, I didn't want it to mess up the grid view. The fact there's an underline there should suffice. People can use long view if they need all the information (same as for symlinks).

[cafkafk]

Thanks for the PR, LGTM 👍