This is part of work to make the flow of files more iterator-able, rather than going in and out of vectors. Here, a Dir returns an iterator of files, rather than a pre-filled vector.
For now, this removes the ability for error messages to be displayed. Will be added in later though!
This is very slow (see #28) at the moment, so there's an option to switch off repo discovery. However, they were still always being queried. Now, if there's no Git option in the flags, it won't try to discover a repo.
These replace `init()` and `tail()` which are deprecated in favour of these.
In fact, it's a good thing they're deprecated, because part of the path_prefix code involved working around a call to init() that would panic otherwise - doing the same check with an `Option` is much more ergonomic.
Previously, each time it tried to render a table (to check its width), it both re-queried the filesystem and re-formatted the values into coloured strings.
These values are now calculated only once before the table is drawn, and are used repeatedly throughout.
Although it looks as though there's more `clone()`ing going on than before, it used to be recalculating things and storing them as vectors anyway, so the memory would still be used in any case.
This commit adds --grid, which, when used with --long, will split the details into multiple columns. Currently this is just 2 columns, but in the future it will be based on the width of the terminal.
In order to do this, I had to do two things:
1. Add a `links` parameter to the filename function, which disables the printing of the arrow and link target in the details view. When this is active, the columns get way too large, and it becomes not worth it.
2. Change the `print_table` function from actually printing the table to stdout to returning a list of `Cells` based on the table. This list then gets its width measured to calculate the width of the resulting table.
Finally! The benefit of having all the field-rendering code (in details.rs) separate from the value-getting code (in file.rs) is that rendering them can be tested again.
Colours are now disabled when output is not to a terminal. Fixes#53!
This required some internal restructuring - colours are now in their own object that gets passed around everywhere it's needed.
Exa now uses the new IO, Path, and Filesystem libraries that have been out for a while now.
Unfortunately, the new libraries don't *entirely* cover the range of the old libraries just yet: in particular, to become more cross-platform, the data in `UnstableFileStat` isn't available in the Unix `MetadataExt` yet. Much of this is contained in rust-lang/rfcs#1044 (which is due to be implemented in rust-lang/rust#14711), but it's not *entirely* there yet.
As such, this commits a serious loss of functionality: no symlink viewing, no hard links or blocks, or users or groups. Also, some of the code could now be optimised. I just wanted to commit this to sort out most of the 'teething problems' of having a different path system in advance.
Here's an example problem that took ages to fix for you, just because you read this far: when I first got exa to compile, it worked mostly fine, except calling `exa` by itself didn't list the current directory. I traced where the command-line options were being generated, to where files and directories were sorted, to where the threads were spawned... and the problem turned out to be that it was using the full path as the file name, rather than just the last component, and these paths happened to begin with `.`, so it thought they were dotfiles.
This module provides feature-specific implementations, and also dummy implementations for when they aren't supported by the system or OS.
Doing it this way limits all the #[cfg(feature)] annotations, as we can now just include the module or not.
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.
These were completely missing because I forgot about them... I added sorting functionality before I added date functionality, but it turns out I didn't even need the datetime library to do this!
However, this implementation feels incomplete. If you sort by the accessed date, it still displays the modified date, so the dates still look out of order. If I were to change the date column for the user, though, then there would still be no header to signify that the column has changed. I'm not sure how to proceed with this, but this is still missing functionality, so in it goes.
This has been mostly done with changes in the datetime crate's suddenly
supporting locales.
It's still important that the user's locale is touched only once and
cached from that point on, so a struct in output::details has been made
public, along with that module. This will change later as that object
gains more and more uses thoughout the codes.
Use the `locale` crate as a dependency to read in the set
thousands-separator character, and pass this to the file size column,
which uses it to add the separators in.
en_GB uses ","
fr_FR uses "" and just displays the numbers in one go.
Add options -u, -U, and -m as shorthand options for displaying different
types of timestamp, not just one. It's possible to have more than one by
specifying more than one of these shorthands, but *not* when used with
--time, as this is only meant to display one at a time.
Using the datetime crate, add an extra column to the --long view that
prints out the modified, accessed, or created timestamp for each file.
Also, let the user pick which one they want to see based on the --time
command-line option.
- Turn the views and main program loop into structs, rather than just as one gigantic function
- Separate views into their own files
The addition of the git column and the tree view meant that a lot of functions now just took extra arguments that didn't seem to fit. For example, it didn't really work to have only one 'view' method that printed out everything, as the different view options now all take different parameters.
FileName was always a special-cased column, as it was assumed to be the last column in the output. Now, it's explicitly marked as such. This allows the hash marks to be placed before the filename, rather than at the start of the line.
There's still a lot to do, but this is actually *something*. The tree hierarchy is displayed using hashes at the start of a line. I want to have it just before the filename, but this will need some changes to the way that columns are handled.
Instead of stripping the ANSI formatting characters from our strings, work out the length without them and use that. This is per-column, but most of them are simple (just the same number of characters in the non-coloured string).
Sometimes, this is really simple: for example, trwxrwxrwx permissions strings are always going to be ten characters long, and the strings that get returned are chock full of ANSI escape codes.
This should have a small benefit on performance.
