I read through every file and applied a couple of rustfmt suggestions. The brace placement and alignment of items on similar lines has been made consistent, even if neither are rustfmt's default style (a file has been put in place to enforce this). Other changes are:
• Alphabetical imports and modules
• Comma placement at the end of match blocks
• Use newlines and indentation judiciously
• Spaces around associated types
• Spaces after negations (it makes it more clear imho)
• Comment formatting
• Use early-returns and Optional `?` where appropriate
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 meddles about with both the Colours and the FileExtensions.
Even though all the renderable fields were turned into traits, the FileName struct kept on accessing fields directly on the Colours value instead of calling methods on it. It also did the usual amount of colour misappropriation (such as ‘punctuation’ instead of specifying ‘normal_arrow’)
In preparation for when custom file colours are configurable (any day now), the colourise-file-by-kind functionality (links, sockets, or directories) was separated from the colourise-file-by-name functionality (images, videos, archives). The FileStyle struct already allowed for both to be separate; it was only changed so that a type other than FileExtensions could be used instead, as long as it implements the FileColours trait. (I feel like I should re-visit the naming of all these at some point in the future)
The decision to separate the two means that FileExtensions is the one assigning the colours, rather than going through the fields on a Colours value, which have all been removed. This is why a bunch of arbitrary Styles now exist in filetype.rs.
Because the decision on which colourise-file-by-name code to use (currently just the standard extensions, or nothing if we aren’t colourising) is now determined by the Colours type (instead of being derived), it’s possible to get it wrong. And wrong it was! There was a bug where file names were colourised even though the rest of the --long output wasn’t, and this wasn’t caught by the xtests. It is now.
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.
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.
This turns `file` into `self.file` and `colours` into `self.colours`, but it means we don’t need to pass arguments everywhere, which will be more of a problem the more functions there are.
Most of the code has just been indented.
This commit moves file, dir, and the feature modules into one parent 'fs' module. Now there are three main 'areas' of the code: main and options, the filesystem-touching code, and the output-displaying code.
It should be the case that nothing in 'output' touches 'std::fs'.
This commit changes all the views to accommodate printing each path's prefix, if it has one.
Previously, each file was stripped of its ancestry, leaving only its file name to be displayed. So running "exa /usr/bin/*" would display only filenames, while running "ls /usr/bin/*" would display each file prefixed with "/usr/bin/". But running "ls /usr/bin/" -- without the glob -- would run ls on just the directory, printing out the file names with no prefix or anything.
This functionality turned out to be useful in quite a few situations: firstly, if the user passes in files from different directories, it would be hard to tell where they came from (especially if they have the same name, such as find | xargs). Secondly, this also applied when following symlinks, making it unclear exactly which file a symlink would be pointing to.
The reason that it did it this way beforehand was that I didn't think of these use-cases, rather than for any technical reason; this new method should not have any drawbacks save making the output slightly wider in a few cases. Compatibility with ls is also a big plus.
Fixes#104, and relates to #88 and #92.
This commit moves the colours module to be a sub-module of the output one.
This makes sense because finding which colour a certain file should be is only
done during output, and (I think) the only places that the `Colours` struct's
fields are ever queried is from the output module.
The only casualty was that the `file_colour` from the filetype module had to
be moved, as determining colours is no longer part of that module - only
determining filetype is. So it now reflects its name!
A recent change to ansi-term [1] means that `ANSIString`s can now hold either
owned *or* borrowed data (Rust calls this the Cow type). This means that we
can delay formatting ANSIStrings into ANSI-control-code-formatted strings
until it's absolutely necessary. The process for doing this was:
1. Replace the `Cell` type with a `TextCell` type that holds a vector of
`ANSIString` values instead of a formatted string. It still does the
width tracking.
2. Rework the details module's `render` functions to emit values of this
type.
3. Similarly, rework the functions that produce cells containing filenames
to use a `File` value's `name` field, which is an owned `String` that
can now be re-used.
4. Update the printing, formatting, and width-calculating code in the
details and grid-details views to produce a table by adding vectors
together instead of adding strings together, delaying the formatting as
long as it can.
This results in fewer allocations (as fewer `String` values are produced), and
makes the API tidier (as fewer `String` values are being passed around without
having their contents specified).
This also paves the way to Windows support, or at least support for
non-ANSI terminals: by delaying the time until strings are formatted,
it'll now be easier to change *how* they are formatted.
Casualties include:
- Bump to ansi_term v0.7.1, which impls `PartialEq` and `Debug` on
`ANSIString`.
- The grid_details and lines views now need to take a vector of files, rather
than a borrowed slice, so the filename cells produced now own the filename
strings that get taken from files.
- Fixed the signature of `File#link_target` to specify that the
file produced refers to the same directory, rather than some phantom
directory with the same lifetime as the file. (This was wrong from the
start, but it broke nothing until now)
References:
[1]: ansi-term@f6a6579ba8174de1cae64d181ec04af32ba2a4f0
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.
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.
- 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.
Benjamin Sago
Bond_009
Alex Soderman
TSUYUSATO Kitsune