2016-04-16 21:05:50 +00:00
|
|
|
|
//! Tests for various types of file (video, image, compressed, etc).
|
|
|
|
|
//!
|
|
|
|
|
//! Currently this is dependent on the file’s name and extension, because
|
|
|
|
|
//! those are the only metadata that we have access to without reading the
|
|
|
|
|
//! file’s contents.
|
|
|
|
|
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
use ansi_term::Style;
|
|
|
|
|
|
2018-12-07 23:43:31 +00:00
|
|
|
|
use crate::fs::File;
|
|
|
|
|
use crate::output::file_name::FileColours;
|
|
|
|
|
use crate::output::icons::FileIcon;
|
2014-06-17 08:35:40 +00:00
|
|
|
|
|
2015-06-08 20:33:39 +00:00
|
|
|
|
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
#[derive(Debug, Default, PartialEq)]
|
2017-07-10 12:31:20 +00:00
|
|
|
|
pub struct FileExtensions;
|
|
|
|
|
|
|
|
|
|
impl FileExtensions {
|
2016-04-16 21:05:50 +00:00
|
|
|
|
|
|
|
|
|
/// An “immediate” file is something that can be run or activated somehow
|
|
|
|
|
/// in order to kick off the build of a project. It’s usually only present
|
|
|
|
|
/// in directories full of source code.
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
fn is_immediate(&self, file: &File) -> bool {
|
2019-10-03 20:40:33 +00:00
|
|
|
|
file.name.to_lowercase().starts_with("readme") ||
|
|
|
|
|
file.name.ends_with(".ninja") ||
|
|
|
|
|
file.name_is_one_of( &[
|
2015-05-09 15:10:26 +00:00
|
|
|
|
"Makefile", "Cargo.toml", "SConstruct", "CMakeLists.txt",
|
2020-01-19 14:08:07 +00:00
|
|
|
|
"build.gradle", "pom.xml", "Rakefile", "package.json", "Gruntfile.js",
|
2019-10-03 20:40:33 +00:00
|
|
|
|
"Gruntfile.coffee", "BUILD", "BUILD.bazel", "WORKSPACE", "build.xml",
|
|
|
|
|
"webpack.config.js", "meson.build",
|
2015-05-09 15:10:26 +00:00
|
|
|
|
])
|
2015-05-12 02:08:24 +00:00
|
|
|
|
}
|
2015-05-09 15:10:26 +00:00
|
|
|
|
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
fn is_image(&self, file: &File) -> bool {
|
2017-07-10 12:31:20 +00:00
|
|
|
|
file.extension_is_one_of( &[
|
2015-05-09 15:10:26 +00:00
|
|
|
|
"png", "jpeg", "jpg", "gif", "bmp", "tiff", "tif",
|
|
|
|
|
"ppm", "pgm", "pbm", "pnm", "webp", "raw", "arw",
|
2019-04-03 18:10:03 +00:00
|
|
|
|
"svg", "stl", "eps", "dvi", "ps", "cbr", "jpf",
|
2017-08-06 10:47:15 +00:00
|
|
|
|
"cbz", "xpm", "ico", "cr2", "orf", "nef",
|
2015-05-09 15:10:26 +00:00
|
|
|
|
])
|
2015-05-12 02:08:24 +00:00
|
|
|
|
}
|
2015-05-09 15:10:26 +00:00
|
|
|
|
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
fn is_video(&self, file: &File) -> bool {
|
2017-07-10 12:31:20 +00:00
|
|
|
|
file.extension_is_one_of( &[
|
2018-10-02 05:47:51 +00:00
|
|
|
|
"avi", "flv", "m2v", "m4v", "mkv", "mov", "mp4", "mpeg",
|
2017-08-04 14:03:16 +00:00
|
|
|
|
"mpg", "ogm", "ogv", "vob", "wmv", "webm", "m2ts",
|
2015-05-09 15:10:26 +00:00
|
|
|
|
])
|
2015-05-12 02:08:24 +00:00
|
|
|
|
}
|
2015-05-09 15:10:26 +00:00
|
|
|
|
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
fn is_music(&self, file: &File) -> bool {
|
2017-07-10 12:31:20 +00:00
|
|
|
|
file.extension_is_one_of( &[
|
2017-08-04 14:03:16 +00:00
|
|
|
|
"aac", "m4a", "mp3", "ogg", "wma", "mka", "opus",
|
2015-05-09 15:10:26 +00:00
|
|
|
|
])
|
2015-05-12 02:08:24 +00:00
|
|
|
|
}
|
2015-05-09 15:10:26 +00:00
|
|
|
|
|
2016-04-16 21:05:50 +00:00
|
|
|
|
// Lossless music, rather than any other kind of data...
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
fn is_lossless(&self, file: &File) -> bool {
|
2017-07-10 12:31:20 +00:00
|
|
|
|
file.extension_is_one_of( &[
|
2015-05-09 15:10:26 +00:00
|
|
|
|
"alac", "ape", "flac", "wav",
|
|
|
|
|
])
|
2015-05-12 02:08:24 +00:00
|
|
|
|
}
|
2015-05-09 15:10:26 +00:00
|
|
|
|
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
fn is_crypto(&self, file: &File) -> bool {
|
2017-07-10 12:31:20 +00:00
|
|
|
|
file.extension_is_one_of( &[
|
2016-04-16 21:17:12 +00:00
|
|
|
|
"asc", "enc", "gpg", "pgp", "sig", "signature", "pfx", "p12",
|
2015-05-09 15:10:26 +00:00
|
|
|
|
])
|
2015-05-12 02:08:24 +00:00
|
|
|
|
}
|
2015-05-09 15:10:26 +00:00
|
|
|
|
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
fn is_document(&self, file: &File) -> bool {
|
2017-07-10 12:31:20 +00:00
|
|
|
|
file.extension_is_one_of( &[
|
2015-05-09 15:10:26 +00:00
|
|
|
|
"djvu", "doc", "docx", "dvi", "eml", "eps", "fotd",
|
|
|
|
|
"odp", "odt", "pdf", "ppt", "pptx", "rtf",
|
|
|
|
|
"xls", "xlsx",
|
|
|
|
|
])
|
2015-05-12 02:08:24 +00:00
|
|
|
|
}
|
2015-05-09 15:10:26 +00:00
|
|
|
|
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
fn is_compressed(&self, file: &File) -> bool {
|
2017-07-10 12:31:20 +00:00
|
|
|
|
file.extension_is_one_of( &[
|
2017-08-07 03:04:24 +00:00
|
|
|
|
"zip", "tar", "Z", "z", "gz", "bz2", "a", "ar", "7z",
|
|
|
|
|
"iso", "dmg", "tc", "rar", "par", "tgz", "xz", "txz",
|
2019-10-03 20:40:33 +00:00
|
|
|
|
"lz", "tlz", "lzma", "deb", "rpm", "zst",
|
2015-05-09 15:10:26 +00:00
|
|
|
|
])
|
2015-05-12 02:08:24 +00:00
|
|
|
|
}
|
2015-05-09 15:10:26 +00:00
|
|
|
|
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
fn is_temp(&self, file: &File) -> bool {
|
2017-07-10 12:31:20 +00:00
|
|
|
|
file.name.ends_with('~')
|
|
|
|
|
|| (file.name.starts_with('#') && file.name.ends_with('#'))
|
2017-09-18 03:08:25 +00:00
|
|
|
|
|| file.extension_is_one_of( &[ "tmp", "swp", "swo", "swn", "bak", "bk" ])
|
2015-05-12 02:08:24 +00:00
|
|
|
|
}
|
2015-05-09 15:10:26 +00:00
|
|
|
|
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
fn is_compiled(&self, file: &File) -> bool {
|
2020-01-19 14:08:07 +00:00
|
|
|
|
if file.extension_is_one_of( &[ "class", "elc", "hi", "o", "pyc", "zwc" ]) {
|
2015-05-09 15:10:26 +00:00
|
|
|
|
true
|
Use new io + path + fs libraries (LOTS OF CHANGES)
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.
2015-04-23 12:00:34 +00:00
|
|
|
|
}
|
2017-07-10 12:31:20 +00:00
|
|
|
|
else if let Some(dir) = file.parent_dir {
|
|
|
|
|
file.get_source_files().iter().any(|path| dir.contains(path))
|
2014-06-17 08:35:40 +00:00
|
|
|
|
}
|
2015-05-09 15:10:26 +00:00
|
|
|
|
else {
|
|
|
|
|
false
|
2014-06-17 08:35:40 +00:00
|
|
|
|
}
|
2015-05-12 02:08:24 +00:00
|
|
|
|
}
|
2014-06-17 08:35:40 +00:00
|
|
|
|
}
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
|
|
|
|
|
impl FileColours for FileExtensions {
|
|
|
|
|
fn colour_file(&self, file: &File) -> Option<Style> {
|
|
|
|
|
use ansi_term::Colour::*;
|
|
|
|
|
|
|
|
|
|
Some(match file {
|
2018-10-14 15:21:13 +00:00
|
|
|
|
f if self.is_temp(f) => Fixed(244).normal(),
|
Extract trait above file name colours
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.
2017-08-26 19:43:47 +00:00
|
|
|
|
f if self.is_immediate(f) => Yellow.bold().underline(),
|
|
|
|
|
f if self.is_image(f) => Fixed(133).normal(),
|
|
|
|
|
f if self.is_video(f) => Fixed(135).normal(),
|
|
|
|
|
f if self.is_music(f) => Fixed(92).normal(),
|
|
|
|
|
f if self.is_lossless(f) => Fixed(93).normal(),
|
|
|
|
|
f if self.is_crypto(f) => Fixed(109).normal(),
|
|
|
|
|
f if self.is_document(f) => Fixed(105).normal(),
|
|
|
|
|
f if self.is_compressed(f) => Red.normal(),
|
|
|
|
|
f if self.is_compiled(f) => Fixed(137).normal(),
|
|
|
|
|
_ => return None,
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-03-27 17:00:38 +00:00
|
|
|
|
|
|
|
|
|
impl FileIcon for FileExtensions {
|
|
|
|
|
fn icon_file(&self, file: &File) -> Option<char> {
|
2018-12-07 23:43:31 +00:00
|
|
|
|
use crate::output::icons::Icons;
|
2018-03-27 17:00:38 +00:00
|
|
|
|
|
|
|
|
|
Some(match file {
|
|
|
|
|
f if self.is_music(f) || self.is_lossless(f) => Icons::Audio.value(),
|
|
|
|
|
f if self.is_image(f) => Icons::Image.value(),
|
|
|
|
|
f if self.is_video(f) => Icons::Video.value(),
|
|
|
|
|
_ => return None,
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
}
|