This commit makes changes to the way variables are referenced:
• Make types Copy when possible
• Make methods take `self` instead of `&self` where possible (trivially_copy_pass_by_ref)
• Remove unnecessary borrowing (needless_ref)
• Remove unnecessary cloning (clone_on_copy)
• Remove `ref` from match arms where possible (new Rust match ergonomics)
This commit removes the env_logger dependency, replacing it with a simple implementation. Doing so removes like ten other transitive dependencies that no longer need to be included in the build.
It also gains the ability to enable trace-level logging. The users crate, which contains such logging statements as of the version I published a few days ago, has been upgraded to celebrate.
Also, change the log imports to globs. I'm only interested that a file doing logging, not what level it's logging at.
This was an unintended consequence of #653. The Files iterator stopped using IgnoreCache and started using GitCache, which would always populated when the `--git` option was passed, without checking whether files were meant to be ignored. This meant that passing `--git` started ignoring files even without `--git-ignore`.
The solution for now is to explicitly pass the flag around, which probably should be a better type than bool but isn't. This makes the git-ignoring-related extended tests pass.
This improves performance by a factor of at least 2 in large --tree workloads by avoiding the repeated creation/destruction of the pool and containing threads.
Cycling pools also encountered lots lock contention, which accounted for most of the time saved by reusing a single pool.
This is all a big commit because it took a lot more work than I thought it would! The commit basically moves Git repositories from being per-directory to living for the whole life of the program. This allows for several directories in the same repository to be listed in the same invocation; before, it would try to rediscover the repository each time! This is why two of the tests “broke”: it suddenly started working with --recurse.
The Dir type does now not use Git at all; because a Dir doesn’t have a Git, then a File doesn’t have one either, so the Git cache gets passed to the render functions which will put them in the Table to render them.
This commit adds a cache for Git repositories based on the path being queried.
Its only immediate effect is that when you query the same directory twice (such as /testcases/git /testcases/git), it won’t need to check that the second one is a Git directory the second time. So, a minuscule optimisation for something you’d never do anyway? Wrong! It’s going to let us combine multiple entries over the same repository later, letting us use --tree and --recurse, because now Git scanning is behind a factory.
The error in #178 was being hidden from output most of the time, and because exa isn’t a GUI program, there’s nowhere it can really dump log output like this. Now that users can opt in with the EXA_DEBUG variable, there is a place it can go.
Also stop the ERROR log level being printed by default.
exa now ignores errors when checking for extended attributes when the user didn’t explicitly demand that they be checked. If a file does have xattrs, it’ll still display the @ in the permissions column; errors will now just cause the @ to be hidden instead.
This changed a lot of the xtests, which were displaying the error message in a few situations. Those tests have gained @-suffixed companions so the actual error messages can still be tested.
Fixes#178 (finally)
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.
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.
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.
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.
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.
Adding a header row automatically added the widths to the table and returned the row, but adding a file’s row didn’t add the widths. Now they’re consistent.
By having the widths be in a separate type, we can separate the two out later, rather than having one refer to the other.
This commit ties a table’s Environment to the fact that it contains columns.
Previously, the Details view would get its Environment, and then use those fields to actually display the details in the table: except for the case where we’re only displaying a tree, when it would just be ignored, instead.
This was caused by the “no columns” case using a Vec of no Columns behind the scenes, rather than disabling the table entirely; much like how a tap isn’t a zero-length swipe, the code should have been updated to reflect this. Now, the Environment is only created if it’s going to be used.
Also, fix a double-mutex-lock: the mutable Table had to be accessed under a lock, but the table contained a UsersCache, which *also* had to be accessed under a lock. This was changed so that the table is only updated *after* the threads have all been joined, so there’s no need for any lock at all. May fix#141, but not sure.
This commit extracts the common table element from the details and grid_details modules, and makes it its own reusable thing.
- A Table no longer holds the values it’s rendering; it just holds a continually-updated version of the maximum widths for each column. This means that all of the resulting values that turn into Rows — which here are either files, or file eggs — need to be stored *somewhere*, and that somewhere is a secondary vector that gets passed around and modified alongside the Table.
- Likewise, all the mutable methods that were on Table that added a Row now *return* the row that would have been added, hoping that the row does get stored somewhere. (It does, don’t worry.)
- Because rendering with mock users is tested in the user-field-rendering module, we don’t need to bother threading different types of U through the Environment, so now it’s just been specialised to UsersCache.
- Accidentally speed up printing a table by not buffering its entire output first when not necessary.
There was a problem when displaying . and .. in directory listings: their names would normalise to actual names! So instead of literally seeing `.`, you’d see the current directory’s name, inserted in sort order into the list of results. Obviously this is not what we want.
In unrelated news, putting `.` and `..` into the list of paths read from a directory just takes up more heap space for something that’s basically constant.
We can solve both these problems at once by moving the DotFilter to the files iterator in Dir, rather than at the Dir’s creation. Having the iterator know whether it should display `.` and `..` means it can emit those files first, and because it knows what those files really represent, it can override their file names to actually be those sequences of dots.
This is not a perfect solution: the main casualty is that a File can now be constructed with a name, some metadata, both, or neither. This is currently handled with a bunch of Options, and returns IOResult even without doing any IO operations.
But at least all the tests pass!
I originally thought that the entries . and .. were in *every* directory entry, and exa was already doing something to filter it out. And then... I could find no such code! Turns out, if we want those entries present, we have to insert them ourselves.
This was harder than expected. Because the file filter doesn’t have access to the parent directory path, it can’t “filter” the files vector by inserting the files at the beginning.
Instead, we do it at the iterator level. A directory can be scanned in three different ways depending on what sort of dotfiles, if any, are wanted. At this point, we already have access to the parent directory’s path, so we can just insert them manually. The enum got moved to the dir module because it’s used most there.
These two fields were originally needed to determine how to recurse when using tree view.
However, as there was no distinction between the “options parsed from the command-line” Details and the “values needed to render a table” Details, these had to be threaded through the options parser as a special-case to end up in the right struct.
No more! Because there are separate structs for options and rendering, we can just add them in later.
Instead of having render methods on the types that are now called Options, create new Render structs (one per view) and execute them. This means that it’s easier to extract methods from them — some of them are pretty long.
Also, remove the GridDetails struct, which got consumed by Mode (mostly)
By introducing another indirection between the structs that command-line options get parsed into and the structs that get rendered, it should be easier to refactor that horrible function in view.rs.
All four view types — lines, grid, details, and grid-details — held their own colours and classify flags.
This didn’t make any sense for the grid-details view, which had to pick which one to use: the values were in there twice.
It also gave the Table in the details view access to more information than it really should have had.
Now, those two flags are returned separately from the view “mode”, which is the new term for one of those four things.
