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 uses Clippy to fix all the 'use_self' warnings. Using Self instead of the type name has been good Rust style for a while now, and it's become the style I'm used to seeing.
Fixes#288, but more-or-less as a side-effect.
The “mi” key in LS_COLORS was meant to be used for a missing link path, but it wasn’t really used like that. There was also a bug where control characters in a broken symlink’s path were assumed to be underlined, because that’s what happened in the default colour scheme, but this assumption doesn’t hold when colours were disabled.
The solution to these was not to introduce another configurable colour code, but to start using _overlays_ to alter a bunch of colours at once. The “mi” code will have to be added back later.
This commit adds to the parsing of the LS_COLORS and EXA_COLORS variables so that non-two-letter codes (keys other than things like ‘di’ or ‘ln’ or ‘ex’) will be treated as file name globs, and get used to colour files accordingly.
Fixes#116 for good.
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.
There are now two device colours instead of one. Even though they’re both set to the same style for the default colour set, LS_COLORS allows the two to look different, so exa has to support it too.
It’s probably a good idea to support it anyway.
This separates the colours to give to files with different filesystem types (directories, links, sockets) from files with different names or extensions (images, videos, archives).
I’m not 100% sure I’ve got the terms “kind” and “type” the right way round, but whatever.
This was done because colouring files based on their name is going to be handled differently and extensibly from colouring files based on what the filesystem thinks.
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.
The arguments passed to File’s constructor were different from the field names used — these might as well both be the same.
Also, move ext and filename to be File methods to save an import, and add tests.
Also also, by passing a PathBuf in to the constructor directly, we can save one (possibly two) instance/s where we pass in a reference to something we were going to lose ownership of anyway, only to have it basically cloned.
Because the link style and status are now both available to the function that picks the colour style, we can have it highlight broken links differently.
Fixes#131.
Doing this meant that the escaping functionality got used in three places, so it was extracted into a generalised function in its own module.
This is slighly slower for the case where escaped characters are displayed in the same colour as the displayable characters, which happens when listing a directory’s name when recursing. Optimise this, yeah?
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.
Benjamin Sago
Benjamin Sago
Alexandru-Sergiu Marton
Bond_009