In cases where symlink targets were more than a single directory down,
exa did not print the '/' targets when separating directories, resulting
in the following output:
symlink => dirAdirBdirC/file
Instead of
symlink => dirA/dirB/dirC/file
By adding a '/' character after each component of the filename, this
error is fixed.
The old implementation blindly assumed that a symlink target would have a directory compoment, which the current directory, parent directory, and root directory technically don't have.
Fixes#20.
The logic of the previous version wasn't correct. Also, presuming
natural ordering of full filenames is still reasonable when the
extensions are identical.
The challenge is that the paths returned from libgit2's status listing
are from the perspective of the Git repository and thus effectively
relative to the working tree root, while the other paths we're
manipulating are (potentially) relative to our current working
directory. So, if those two aren't identical (if running from outside
the working tree, or from a subdirectory), the paths won't match up.
A reasonably reliable way around this is to resolve both types of paths
to absolute paths before comparing them. This fixes#15 at a basic
level, anyway.
What still doesn't work: referring to the working tree or one of its
descendants via a symlink. For that, we'd probably need to fully resolve
symlinks in the file path.
(The unwrap_or()'s are messy and will probably just result in missing
status information, but then, what information could you hope to get
without having both a current working directory and a Git working tree?)
Filenames with characters that need multiple bytes in UTF-8, and/or
control characters like combining diacritics, would break the grid.
`StrExt::width` seems to do the right thing, and there's conveniently a
function here (which was otherwise unused) to call that.
