This commit moves the definitions of Filter and DirAction from the options module to the fs module, but leaves the parts that actually have to do with option parsing alone.

Now, the options module shouldn’t define any types that get used elsewhere in the program: it only adds functionality to types that already exist.

Even though these can’t actually be viewed with `cargo doc` yet, they’re still good to have around.

Casualty here was that you can’t have static values reference one another directly, so the static args slice had to be turned into a slice *of references* rather than of values. No big deal, just have to write & a few more times.

Every time looking up an argument fails, it returns an error. We might as well just move this into the lookup function.

All the tests pass, but only half the functionality is there right now.

This creates a new type that holds file extensions in preparation for #116. It doesn’t do anything yet, but it will!

The FileExtensions in the FileName is now a reference to the one in the original FileStyle, which gets put there in the options module.

This allows the extensions to be derived from the user, somehow, in the future when that part’s done.

Instead of having a File do its own extension checking, create a new type that takes a file and checks *that*. This new type (FileExtensions) is currently empty, but were it to contain values, those values could be used to determine the file’s colour.

This commit replaces the “two normal cases” of showing a link’s target or not with “one default and one special case” of preferring to hide them, displaying the link targets by setting a flag instead.

Doing this simplifies the file name constructor, which gets to remove an argument.

The new FileStyles value will contain all the fields necessary to “style” a file’s name. Right now this is only the Classify field, but there can be more later. The benefit of this is that when we add more, we won’t need to update all the places where file names are displayed.

For #132. Users had to be updated for the version number.

This merges in the ability to use different time styles, such as full ISO-formatted timestamps instead of just using the default variable style.

Firstly, this moved the Environment from the Table to the Columns, so it 1) would only be instantiated when a table is actually used, and 2) can be affected by command-line options.

Next, it renames Columns to table::Options, in line with what the view optionses were renamed to.

Finally, it adds support for more time styles, deferring timestamp formatting to an enum.

Fixes #133.

This has to do its own number formatting because *somebody* didn’t add “print the current month number” functionality to rust-datetime!

The information was always in the Metadata struct; exa just never used it.

It used the mtime, rather than the atime. Copy and paste error. Whoops!

By moving it outside of the Environment::load_all() constructor, it can be set to different values.

This commit moves the Environment field from the Table to its Options, and properly gets rid of the name ‘columns’ from the last commit.

Having it in the Options is important, because it means it can be generated from some command-line options. Also, it reduces the number of arguments that need to be passed to Table::new; there would have been 4 with the inclusion of the Environment, but by moving some of the code into the function, we can avoid this (and any further arguments).

The views have been renamed to be the Optionses of their module; now the options for the Table — Columns — has followed suit.

This works out, because the table module depended on everything in the columns module. It opens the door for other only-table-specific things to be included.

The casualty was that by making it non-Clone and non-PartialEq, a bunch of other #[derive]-d types had to have their derivions removed too.

The Environment struct only used the Default trait so it could have the same call for both Environment<UsersCache> and Environment<MockUsers>. There’s no reason to keep it around anymore.

This commit merges in a *lot* of refactoring work done to the tree, details, and grid-details views.

The main one is that the concept of a “table” has been completely separated from the details view. Previously, if you wanted to use the long view without drawing the table (such as with --tree), exa used a “table” with 0 columns in it behind the scenes. This is now reversed: the table is now the optional component in the details view, and a tree-only view is just a details view without a table!

Doing this has paved the way for all sorts of code cleanups: now, we only calculate values needed for the table if one’s going to be displayed. Some of these were rather expensive to compute (such as the user’s time zone, or locale)

This refactoring is not fully complete; there are still several things that can be done, including having the errors and xattrs in the tree view use the same TreeParams constructor as the others, and separating the column widths from the table so fewer mutable values need to be passed around.

Finally, this also merges in a lot of debuffering. There were at least two places in the code where values were collected into a vector before immediately being iterated over, instead of just using those values as they were generated! For example, when displaying the table, each row was rendered into a set of cells for displaying: but then it all went into a vector, and was only displayed at the very end, because that was what I needed for the grid-details view. Now, exa is smart enough to not do that.

Basically, even if exa doesn’t actually *get* that much faster, it should at least display its first line of output quicker.

Fixes #90, but also see #82.

There was a bug where if you tried to recurse into a directory you didn’t have permission to read the contents of, the error would be ignored.

It now displays the errors.

It now tests a lot more combinations of xattrs on files, as well as xattrs and files and errors as the children of directories.

The recent code changes have touched the part where directories’ xattrs and children are displayed at the same tree level, and there weren’t enough tests for this.

The goal of this part of the refactoring, if you wondered, is to make it so only the tree module is aware that it needs ‘depth’ and ‘last’ values to draw the tree.

As far as the details module is concerned, it should just be doing something to produce TreeParams values which it later consumes; that’s it.

This change should make it easier to have tables that may or may not have a tree in them.

It only really gets used for zeroes and having one added to it.

The fields for ‘depth’ and ‘last’ were being passed around separately, but were always used together.