2020-10-13 00:36:41 +00:00
|
|
|
|
#![warn(deprecated_in_future)]
|
|
|
|
|
#![warn(future_incompatible)]
|
|
|
|
|
#![warn(nonstandard_style)]
|
|
|
|
|
#![warn(rust_2018_compatibility)]
|
|
|
|
|
#![warn(rust_2018_idioms)]
|
2015-09-04 10:17:59 +00:00
|
|
|
|
#![warn(trivial_casts, trivial_numeric_casts)]
|
2020-10-13 00:36:41 +00:00
|
|
|
|
#![warn(unused)]
|
2015-09-04 10:17:59 +00:00
|
|
|
|
|
2020-10-13 00:46:17 +00:00
|
|
|
|
#![warn(clippy::all, clippy::pedantic)]
|
2021-05-08 14:37:53 +00:00
|
|
|
|
#![allow(clippy::cast_precision_loss)]
|
|
|
|
|
#![allow(clippy::cast_possible_truncation)]
|
|
|
|
|
#![allow(clippy::cast_possible_wrap)]
|
|
|
|
|
#![allow(clippy::cast_sign_loss)]
|
2020-10-13 00:46:17 +00:00
|
|
|
|
#![allow(clippy::enum_glob_use)]
|
|
|
|
|
#![allow(clippy::map_unwrap_or)]
|
|
|
|
|
#![allow(clippy::match_same_arms)]
|
|
|
|
|
#![allow(clippy::module_name_repetitions)]
|
|
|
|
|
#![allow(clippy::non_ascii_literal)]
|
|
|
|
|
#![allow(clippy::option_if_let_else)]
|
|
|
|
|
#![allow(clippy::too_many_lines)]
|
2021-05-11 22:32:12 +00:00
|
|
|
|
#![allow(clippy::unnested_or_patterns)] // TODO: remove this when we support Rust 1.53.0
|
2020-10-13 00:46:17 +00:00
|
|
|
|
#![allow(clippy::unused_self)]
|
Cleanup clippy warnings
warning: explicit lifetimes given in parameter types where they could be elided (or replaced with `'_` if needed by type declaration)
--> src/output/escape.rs:4:1
|
4 | pub fn escape<'a>(string: String, bits: &mut Vec<ANSIString<'a>>, good: Style, bad: Style) {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
warning: this lifetime isn't used in the function definition
--> src/output/escape.rs:4:15
|
4 | pub fn escape<'a>(string: String, bits: &mut Vec<ANSIString<'_>>, good: Style, bad: Style) {
| ^^
|
warning: single-character string constant used as pattern
--> src/output/table.rs:310:41
|
310 | if file.starts_with(":") {
| ^^^ help: try using a `char` instead: `':'`
|
warning: single-character string constant used as pattern
--> src/output/table.rs:310:41
|
310 | if file.starts_with(":") {
| ^^^ help: try using a `char` instead: `':'`
|
warning: methods called `new` usually return `Self`
--> src/output/render/git.rs:38:5
|
38 | fn new(&self) -> Style;
| ^^^^^^^^^^^^^^^^^^^^^^^
|
warning: this lifetime isn't used in the function definition
--> src/output/icons.rs:40:22
|
40 | pub fn iconify_style<'a>(style: Style) -> Style {
| ^^
|
warning: lint `clippy::find_map` has been removed: this lint has been replaced by `manual_find_map`, a more specific lint
--> src/main.rs:11:10
|
11 | #![allow(clippy::find_map)]
| ^^^^^^^^^^^^^^^^
|
warning: redundant else block
--> src/fs/dir.rs:124:18
|
124 | else {
| __________________^
125 | | return None
126 | | }
| |_____________^
|
warning: redundant else block
--> src/options/view.rs:60:18
|
60 | else {
| __________________^
61 | | // the --tree case is handled by the DirAction parser later
62 | | return Ok(Self::Details(details));
63 | | }
| |_____________^
|
warning: all variants have the same postfix: `Bytes`
--> src/output/table.rs:170:1
|
170 | / pub enum SizeFormat {
171 | |
172 | | /// Format the file size using **decimal** prefixes, such as “kilo”,
173 | | /// “mega”, or “giga”.
... |
181 | | JustBytes,
182 | | }
| |_^
|
warning: all variants have the same postfix: `Bytes`
--> src/output/table.rs:171:1
|
171 | / pub enum SizeFormat {
172 | |
173 | | /// Format the file size using **decimal** prefixes, such as “kilo”,
174 | | /// “mega”, or “giga”.
... |
182 | | JustBytes,
183 | | }
| |_^
|
warning: useless use of `format!`
--> src/options/mod.rs:181:50
|
181 | return Err(OptionsError::Unsupported(format!(
| __________________________________________________^
182 | | "Options --git and --git-ignore can't be used because `git` feature was disabled in this build of exa"
183 | | )));
| |_____________^ help: consider using `.to_string()`: `"Options --git and --git-ignore can't be used because `git` feature was disabled in this build of exa".to_string()`
|
warning: stripping a prefix manually
--> src/fs/filter.rs:287:33
|
287 | if n.starts_with('.') { &n[1..] }
| ^^^^^^^
|
warning: case-sensitive file extension comparison
--> src/info/filetype.rs:24:19
|
24 | file.name.ends_with(".ninja") ||
| ^^^^^^^^^^^^^^^^^^^
|
2021-04-30 13:37:31 +00:00
|
|
|
|
#![allow(clippy::upper_case_acronyms)]
|
2020-10-13 00:46:17 +00:00
|
|
|
|
#![allow(clippy::wildcard_imports)]
|
|
|
|
|
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
use std::env;
|
2017-07-26 16:48:18 +00:00
|
|
|
|
use std::ffi::{OsStr, OsString};
|
2020-10-12 23:54:06 +00:00
|
|
|
|
use std::io::{self, Write, ErrorKind};
|
2017-06-29 12:07:45 +00:00
|
|
|
|
use std::path::{Component, PathBuf};
|
2014-05-04 20:33:14 +00:00
|
|
|
|
|
2017-05-01 20:54:53 +00:00
|
|
|
|
use ansi_term::{ANSIStrings, Style};
|
|
|
|
|
|
2020-10-10 01:01:12 +00:00
|
|
|
|
use log::*;
|
2018-12-07 23:43:31 +00:00
|
|
|
|
|
|
|
|
|
use crate::fs::{Dir, File};
|
|
|
|
|
use crate::fs::feature::git::GitCache;
|
2020-10-10 18:49:46 +00:00
|
|
|
|
use crate::fs::filter::GitIgnore;
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
use crate::options::{Options, Vars, vars, OptionsResult};
|
2018-12-07 23:43:31 +00:00
|
|
|
|
use crate::output::{escape, lines, grid, grid_details, details, View, Mode};
|
Massive theming and view options refactor
This commit significantly refactors the way that options are parsed. It introduces the Theme type which contains both styling and extension configuration, converts the option-parsing process into a being a pure function, and removes some rather gnarly old code.
The main purpose of the refactoring is to fix GH-318, "Tests fail when not connected to a terminal". Even though exa was compiling fine on my machine and on Travis, it was failing for automated build scripts. This was because of what the option-parsing code was trying to accomplish: it wasn't just providing a struct of the user's settings, it was also checking the terminal, providing a View directly.
This has been changed so that the options module now _only_ looks at the command-line arguments and environment variables. Instead of returning a View, it returns the user's _preference_, and it's then up to the 'main' module to examine the terminal width and figure out if the view is doable, downgrading it if necessary.
The code that used to determine the view was horrible and I'm pleased it can be cut out. Also, the terminal width used to be in a lazy_static because it was queried multiple times, and now it's not in one because it's only queried once, which is a good sign for things going in the right direction.
There are also some naming and organisational changes around themes. The blanket terms "Colours" and "Styles" have been yeeted in favour of "Theme", which handles both extensions and UI colours. The FileStyle struct has been replaced with file_name::Options, making it similar to the views in how it has an Options struct and a Render struct.
Finally, eight unit tests have been removed because they turned out to be redundant (testing --colour and --color) after examining the tangled code, and the default theme has been put in its own file in preparation for more themes.
2020-10-22 21:34:00 +00:00
|
|
|
|
use crate::theme::Theme;
|
2014-12-12 11:17:55 +00:00
|
|
|
|
|
2016-04-16 17:59:25 +00:00
|
|
|
|
mod fs;
|
2016-04-16 21:05:50 +00:00
|
|
|
|
mod info;
|
2020-10-10 01:01:12 +00:00
|
|
|
|
mod logger;
|
2015-05-07 21:20:24 +00:00
|
|
|
|
mod options;
|
|
|
|
|
mod output;
|
Massive theming and view options refactor
This commit significantly refactors the way that options are parsed. It introduces the Theme type which contains both styling and extension configuration, converts the option-parsing process into a being a pure function, and removes some rather gnarly old code.
The main purpose of the refactoring is to fix GH-318, "Tests fail when not connected to a terminal". Even though exa was compiling fine on my machine and on Travis, it was failing for automated build scripts. This was because of what the option-parsing code was trying to accomplish: it wasn't just providing a struct of the user's settings, it was also checking the terminal, providing a View directly.
This has been changed so that the options module now _only_ looks at the command-line arguments and environment variables. Instead of returning a View, it returns the user's _preference_, and it's then up to the 'main' module to examine the terminal width and figure out if the view is doable, downgrading it if necessary.
The code that used to determine the view was horrible and I'm pleased it can be cut out. Also, the terminal width used to be in a lazy_static because it was queried multiple times, and now it's not in one because it's only queried once, which is a good sign for things going in the right direction.
There are also some naming and organisational changes around themes. The blanket terms "Colours" and "Styles" have been yeeted in favour of "Theme", which handles both extensions and UI colours. The FileStyle struct has been replaced with file_name::Options, making it similar to the views in how it has an Options struct and a Render struct.
Finally, eight unit tests have been removed because they turned out to be redundant (testing --colour and --color) after examining the tangled code, and the default theme has been put in its own file in preparation for more themes.
2020-10-22 21:34:00 +00:00
|
|
|
|
mod theme;
|
2014-05-04 16:01:54 +00:00
|
|
|
|
|
2015-06-05 02:04:56 +00:00
|
|
|
|
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
fn main() {
|
|
|
|
|
use std::process::exit;
|
|
|
|
|
|
2020-10-10 01:01:12 +00:00
|
|
|
|
logger::configure(env::var_os(vars::EXA_DEBUG));
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
|
2020-10-10 01:34:54 +00:00
|
|
|
|
let args: Vec<_> = env::args_os().skip(1).collect();
|
2020-10-12 23:29:49 +00:00
|
|
|
|
match Options::parse(args.iter().map(|e| e.as_ref()), &LiveVars) {
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
OptionsResult::Ok(options, mut input_paths) => {
|
|
|
|
|
|
|
|
|
|
// List the current directory by default.
|
|
|
|
|
// (This has to be done here, otherwise git_options won’t see it.)
|
|
|
|
|
if input_paths.is_empty() {
|
|
|
|
|
input_paths = vec![ OsStr::new(".") ];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
let git = git_options(&options, &input_paths);
|
2020-10-12 23:54:06 +00:00
|
|
|
|
let writer = io::stdout();
|
Massive theming and view options refactor
This commit significantly refactors the way that options are parsed. It introduces the Theme type which contains both styling and extension configuration, converts the option-parsing process into a being a pure function, and removes some rather gnarly old code.
The main purpose of the refactoring is to fix GH-318, "Tests fail when not connected to a terminal". Even though exa was compiling fine on my machine and on Travis, it was failing for automated build scripts. This was because of what the option-parsing code was trying to accomplish: it wasn't just providing a struct of the user's settings, it was also checking the terminal, providing a View directly.
This has been changed so that the options module now _only_ looks at the command-line arguments and environment variables. Instead of returning a View, it returns the user's _preference_, and it's then up to the 'main' module to examine the terminal width and figure out if the view is doable, downgrading it if necessary.
The code that used to determine the view was horrible and I'm pleased it can be cut out. Also, the terminal width used to be in a lazy_static because it was queried multiple times, and now it's not in one because it's only queried once, which is a good sign for things going in the right direction.
There are also some naming and organisational changes around themes. The blanket terms "Colours" and "Styles" have been yeeted in favour of "Theme", which handles both extensions and UI colours. The FileStyle struct has been replaced with file_name::Options, making it similar to the views in how it has an Options struct and a Render struct.
Finally, eight unit tests have been removed because they turned out to be redundant (testing --colour and --color) after examining the tangled code, and the default theme has been put in its own file in preparation for more themes.
2020-10-22 21:34:00 +00:00
|
|
|
|
|
|
|
|
|
let console_width = options.view.width.actual_terminal_width();
|
|
|
|
|
let theme = options.theme.to_theme(console_width.is_some());
|
|
|
|
|
let exa = Exa { options, writer, input_paths, theme, console_width, git };
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
match exa.run() {
|
2020-10-10 18:49:46 +00:00
|
|
|
|
Ok(exit_status) => {
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
exit(exit_status);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Err(e) if e.kind() == ErrorKind::BrokenPipe => {
|
|
|
|
|
warn!("Broken pipe error: {}", e);
|
|
|
|
|
exit(exits::SUCCESS);
|
2020-10-10 18:49:46 +00:00
|
|
|
|
}
|
|
|
|
|
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
Err(e) => {
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
eprintln!("{}", e);
|
|
|
|
|
exit(exits::RUNTIME_ERROR);
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
}
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
OptionsResult::Help(help_text) => {
|
2020-10-16 22:53:32 +00:00
|
|
|
|
print!("{}", help_text);
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
OptionsResult::Version(version_str) => {
|
2020-10-16 22:53:32 +00:00
|
|
|
|
print!("{}", version_str);
|
2020-10-10 18:49:46 +00:00
|
|
|
|
}
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
OptionsResult::InvalidOptions(error) => {
|
2021-04-01 10:25:50 +00:00
|
|
|
|
eprintln!("exa: {}", error);
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
if let Some(s) = error.suggestion() {
|
|
|
|
|
eprintln!("{}", s);
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
exit(exits::OPTIONS_ERROR);
|
2020-10-10 18:49:46 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2016-04-18 17:39:32 +00:00
|
|
|
|
/// The main program wrapper.
|
2020-10-10 01:34:54 +00:00
|
|
|
|
pub struct Exa<'args> {
|
2016-04-18 17:39:32 +00:00
|
|
|
|
|
|
|
|
|
/// List of command-line options, having been successfully parsed.
|
2016-04-19 06:48:41 +00:00
|
|
|
|
pub options: Options,
|
2016-04-18 17:39:32 +00:00
|
|
|
|
|
2020-10-10 01:34:54 +00:00
|
|
|
|
/// The output handle that we write to.
|
2020-10-12 23:54:06 +00:00
|
|
|
|
pub writer: io::Stdout,
|
2016-04-19 06:48:41 +00:00
|
|
|
|
|
|
|
|
|
/// List of the free command-line arguments that should correspond to file
|
|
|
|
|
/// names (anything that isn’t an option).
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
pub input_paths: Vec<&'args OsStr>,
|
2017-09-01 18:13:47 +00:00
|
|
|
|
|
Massive theming and view options refactor
This commit significantly refactors the way that options are parsed. It introduces the Theme type which contains both styling and extension configuration, converts the option-parsing process into a being a pure function, and removes some rather gnarly old code.
The main purpose of the refactoring is to fix GH-318, "Tests fail when not connected to a terminal". Even though exa was compiling fine on my machine and on Travis, it was failing for automated build scripts. This was because of what the option-parsing code was trying to accomplish: it wasn't just providing a struct of the user's settings, it was also checking the terminal, providing a View directly.
This has been changed so that the options module now _only_ looks at the command-line arguments and environment variables. Instead of returning a View, it returns the user's _preference_, and it's then up to the 'main' module to examine the terminal width and figure out if the view is doable, downgrading it if necessary.
The code that used to determine the view was horrible and I'm pleased it can be cut out. Also, the terminal width used to be in a lazy_static because it was queried multiple times, and now it's not in one because it's only queried once, which is a good sign for things going in the right direction.
There are also some naming and organisational changes around themes. The blanket terms "Colours" and "Styles" have been yeeted in favour of "Theme", which handles both extensions and UI colours. The FileStyle struct has been replaced with file_name::Options, making it similar to the views in how it has an Options struct and a Render struct.
Finally, eight unit tests have been removed because they turned out to be redundant (testing --colour and --color) after examining the tangled code, and the default theme has been put in its own file in preparation for more themes.
2020-10-22 21:34:00 +00:00
|
|
|
|
/// The theme that has been configured from the command-line options and
|
|
|
|
|
/// environment variables. If colours are disabled, this is a theme with
|
|
|
|
|
/// every style set to the default.
|
|
|
|
|
pub theme: Theme,
|
|
|
|
|
|
|
|
|
|
/// The detected width of the console. This is used to determine which
|
|
|
|
|
/// view to use.
|
|
|
|
|
pub console_width: Option<usize>,
|
|
|
|
|
|
2017-09-01 18:13:47 +00:00
|
|
|
|
/// A global Git cache, if the option was passed in.
|
|
|
|
|
/// This has to last the lifetime of the program, because the user might
|
|
|
|
|
/// want to list several directories in the same repository.
|
|
|
|
|
pub git: Option<GitCache>,
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2015-01-12 18:44:39 +00:00
|
|
|
|
|
2017-08-10 16:54:28 +00:00
|
|
|
|
/// The “real” environment variables type.
|
|
|
|
|
/// Instead of just calling `var_os` from within the options module,
|
|
|
|
|
/// the method of looking up environment variables has to be passed in.
|
|
|
|
|
struct LiveVars;
|
|
|
|
|
impl Vars for LiveVars {
|
|
|
|
|
fn get(&self, name: &'static str) -> Option<OsString> {
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
env::var_os(name)
|
2017-08-10 16:54:28 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-09-01 18:13:47 +00:00
|
|
|
|
/// Create a Git cache populated with the arguments that are going to be
|
|
|
|
|
/// listed before they’re actually listed, if the options demand it.
|
|
|
|
|
fn git_options(options: &Options, args: &[&OsStr]) -> Option<GitCache> {
|
|
|
|
|
if options.should_scan_for_git() {
|
2018-06-19 12:58:03 +00:00
|
|
|
|
Some(args.iter().map(PathBuf::from).collect())
|
2017-09-01 18:13:47 +00:00
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
None
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-10 01:34:54 +00:00
|
|
|
|
impl<'args> Exa<'args> {
|
2021-04-30 13:37:39 +00:00
|
|
|
|
/// # Errors
|
|
|
|
|
///
|
|
|
|
|
/// Will return `Err` if printing to stderr fails.
|
2020-10-12 23:54:06 +00:00
|
|
|
|
pub fn run(mut self) -> io::Result<i32> {
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
debug!("Running with options: {:#?}", self.options);
|
2016-04-19 06:48:41 +00:00
|
|
|
|
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
let mut files = Vec::new();
|
|
|
|
|
let mut dirs = Vec::new();
|
2017-02-26 11:18:46 +00:00
|
|
|
|
let mut exit_status = 0;
|
2015-03-04 02:48:36 +00:00
|
|
|
|
|
Replace Misfire with a testable OptionsResult
This was meant to be a small change, but it spiralled into a big one.
The original intention was to separate OptionsResult and OptionsError. With these types separated, the Help and Version variants can only be returned from the Options::parse function, and the later option-parsing functions can only return success or errors.
Also, Misfire was a silly name.
As a side-effect of Options::parse returning OptionsResult instead of Result<Options, Misfire>, we could no longer use unwrap() or unwrap_err() to get the contents out. This commit makes OptionsResult into a value type, and Options::parse a pure function. It feels like it should be one, having its return value entirely dependent on its arguments, but it also loaded locales and time zones. These parts have been moved into lazy_static references, and the code still passes tests without much change.
OptionsResult isn't PartialEq yet, because the file colouring uses a Box internally.
2020-10-12 22:47:36 +00:00
|
|
|
|
for file_path in &self.input_paths {
|
2018-12-16 07:18:43 +00:00
|
|
|
|
match File::from_args(PathBuf::from(file_path), None, None) {
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
Err(e) => {
|
2017-02-26 11:18:46 +00:00
|
|
|
|
exit_status = 2;
|
2020-10-12 23:54:06 +00:00
|
|
|
|
writeln!(io::stderr(), "{:?}: {}", file_path, e)?;
|
2020-10-10 18:49:46 +00:00
|
|
|
|
}
|
|
|
|
|
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
Ok(f) => {
|
2020-10-10 18:49:46 +00:00
|
|
|
|
if f.points_to_directory() && ! self.options.dir_action.treat_dirs_as_files() {
|
2017-09-01 18:13:47 +00:00
|
|
|
|
match f.to_dir() {
|
2020-10-10 18:49:46 +00:00
|
|
|
|
Ok(d) => dirs.push(d),
|
2020-10-12 23:54:06 +00:00
|
|
|
|
Err(e) => writeln!(io::stderr(), "{:?}: {}", file_path, e)?,
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
else {
|
|
|
|
|
files.push(f);
|
2015-03-04 03:41:30 +00:00
|
|
|
|
}
|
2020-10-10 18:49:46 +00:00
|
|
|
|
}
|
2015-06-05 02:04:56 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
2014-12-12 11:17:55 +00:00
|
|
|
|
|
2016-04-19 06:48:41 +00:00
|
|
|
|
// We want to print a directory’s name before we list it, *except* in
|
|
|
|
|
// the case where it’s the only directory, *except* if there are any
|
|
|
|
|
// files to print as well. (It’s a double negative)
|
|
|
|
|
|
2015-09-05 16:40:02 +00:00
|
|
|
|
let no_files = files.is_empty();
|
2016-04-11 06:48:23 +00:00
|
|
|
|
let is_only_dir = dirs.len() == 1 && no_files;
|
|
|
|
|
|
2016-10-30 14:43:33 +00:00
|
|
|
|
self.options.filter.filter_argument_files(&mut files);
|
2017-03-26 16:35:50 +00:00
|
|
|
|
self.print_files(None, files)?;
|
2016-10-30 14:43:33 +00:00
|
|
|
|
|
2017-02-26 11:18:46 +00:00
|
|
|
|
self.print_dirs(dirs, no_files, is_only_dir, exit_status)
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2014-06-21 17:12:29 +00:00
|
|
|
|
|
2020-10-12 23:54:06 +00:00
|
|
|
|
fn print_dirs(&mut self, dir_files: Vec<Dir>, mut first: bool, is_only_dir: bool, exit_status: i32) -> io::Result<i32> {
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
for dir in dir_files {
|
2015-02-05 14:39:56 +00:00
|
|
|
|
|
2016-04-19 06:48:41 +00:00
|
|
|
|
// Put a gap between directories, or between the list of files and
|
|
|
|
|
// the first directory.
|
2015-02-05 14:39:56 +00:00
|
|
|
|
if first {
|
|
|
|
|
first = false;
|
|
|
|
|
}
|
|
|
|
|
else {
|
2020-10-10 01:34:54 +00:00
|
|
|
|
writeln!(&mut self.writer)?;
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
|
|
|
|
|
2020-10-10 18:49:46 +00:00
|
|
|
|
if ! is_only_dir {
|
2017-05-01 20:54:53 +00:00
|
|
|
|
let mut bits = Vec::new();
|
|
|
|
|
escape(dir.path.display().to_string(), &mut bits, Style::default(), Style::default());
|
2020-10-10 01:34:54 +00:00
|
|
|
|
writeln!(&mut self.writer, "{}:", ANSIStrings(&bits))?;
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
}
|
2015-08-25 14:04:15 +00:00
|
|
|
|
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
let mut children = Vec::new();
|
2020-10-09 23:09:44 +00:00
|
|
|
|
let git_ignore = self.options.filter.git_ignore == GitIgnore::CheckAndIgnore;
|
|
|
|
|
for file in dir.files(self.options.filter.dot_filter, self.git.as_ref(), git_ignore) {
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
match file {
|
2020-10-12 23:54:06 +00:00
|
|
|
|
Ok(file) => children.push(file),
|
|
|
|
|
Err((path, e)) => writeln!(io::stderr(), "[{}: {}]", path.display(), e)?,
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
2016-10-30 14:43:33 +00:00
|
|
|
|
self.options.filter.filter_child_files(&mut children);
|
2015-11-14 23:32:57 +00:00
|
|
|
|
self.options.filter.sort_files(&mut children);
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
|
|
|
|
|
if let Some(recurse_opts) = self.options.dir_action.recurse_options() {
|
|
|
|
|
let depth = dir.path.components().filter(|&c| c != Component::CurDir).count() + 1;
|
2020-10-10 18:49:46 +00:00
|
|
|
|
if ! recurse_opts.tree && ! recurse_opts.is_too_deep(depth) {
|
2015-08-25 14:04:15 +00:00
|
|
|
|
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
let mut child_dirs = Vec::new();
|
2020-10-10 18:49:46 +00:00
|
|
|
|
for child_dir in children.iter().filter(|f| f.is_directory() && ! f.is_all_all) {
|
2017-09-01 18:13:47 +00:00
|
|
|
|
match child_dir.to_dir() {
|
2020-10-12 23:54:06 +00:00
|
|
|
|
Ok(d) => child_dirs.push(d),
|
|
|
|
|
Err(e) => writeln!(io::stderr(), "{}: {}", child_dir.path.display(), e)?,
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2015-02-01 02:14:31 +00:00
|
|
|
|
}
|
|
|
|
|
|
2017-03-26 16:35:50 +00:00
|
|
|
|
self.print_files(Some(&dir), children)?;
|
2017-02-26 11:18:46 +00:00
|
|
|
|
match self.print_dirs(child_dirs, false, false, exit_status) {
|
2020-10-12 23:54:06 +00:00
|
|
|
|
Ok(_) => (),
|
|
|
|
|
Err(e) => return Err(e),
|
2017-02-26 11:18:46 +00:00
|
|
|
|
}
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
continue;
|
2014-07-22 21:19:51 +00:00
|
|
|
|
}
|
Parallelise the details view!
This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)
The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.
There's a lot of large sweeping architectural changes. Here's a smattering of them:
- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.
This also fixes #77, mainly by accident :)
2015-09-02 22:19:10 +00:00
|
|
|
|
}
|
|
|
|
|
|
2017-03-26 16:35:50 +00:00
|
|
|
|
self.print_files(Some(&dir), children)?;
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2016-04-18 17:39:32 +00:00
|
|
|
|
|
2017-02-26 11:18:46 +00:00
|
|
|
|
Ok(exit_status)
|
2015-02-05 14:39:56 +00:00
|
|
|
|
}
|
2014-07-22 21:19:51 +00:00
|
|
|
|
|
2016-04-19 06:48:41 +00:00
|
|
|
|
/// Prints the list of files using whichever view is selected.
|
2020-10-13 00:36:41 +00:00
|
|
|
|
fn print_files(&mut self, dir: Option<&Dir>, files: Vec<File<'_>>) -> io::Result<()> {
|
2020-10-10 18:49:46 +00:00
|
|
|
|
if files.is_empty() {
|
|
|
|
|
return Ok(());
|
|
|
|
|
}
|
2017-06-25 23:53:48 +00:00
|
|
|
|
|
Massive theming and view options refactor
This commit significantly refactors the way that options are parsed. It introduces the Theme type which contains both styling and extension configuration, converts the option-parsing process into a being a pure function, and removes some rather gnarly old code.
The main purpose of the refactoring is to fix GH-318, "Tests fail when not connected to a terminal". Even though exa was compiling fine on my machine and on Travis, it was failing for automated build scripts. This was because of what the option-parsing code was trying to accomplish: it wasn't just providing a struct of the user's settings, it was also checking the terminal, providing a View directly.
This has been changed so that the options module now _only_ looks at the command-line arguments and environment variables. Instead of returning a View, it returns the user's _preference_, and it's then up to the 'main' module to examine the terminal width and figure out if the view is doable, downgrading it if necessary.
The code that used to determine the view was horrible and I'm pleased it can be cut out. Also, the terminal width used to be in a lazy_static because it was queried multiple times, and now it's not in one because it's only queried once, which is a good sign for things going in the right direction.
There are also some naming and organisational changes around themes. The blanket terms "Colours" and "Styles" have been yeeted in favour of "Theme", which handles both extensions and UI colours. The FileStyle struct has been replaced with file_name::Options, making it similar to the views in how it has an Options struct and a Render struct.
Finally, eight unit tests have been removed because they turned out to be redundant (testing --colour and --color) after examining the tangled code, and the default theme has been put in its own file in preparation for more themes.
2020-10-22 21:34:00 +00:00
|
|
|
|
let theme = &self.theme;
|
|
|
|
|
let View { ref mode, ref file_style, .. } = self.options.view;
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
Massive theming and view options refactor
This commit significantly refactors the way that options are parsed. It introduces the Theme type which contains both styling and extension configuration, converts the option-parsing process into a being a pure function, and removes some rather gnarly old code.
The main purpose of the refactoring is to fix GH-318, "Tests fail when not connected to a terminal". Even though exa was compiling fine on my machine and on Travis, it was failing for automated build scripts. This was because of what the option-parsing code was trying to accomplish: it wasn't just providing a struct of the user's settings, it was also checking the terminal, providing a View directly.
This has been changed so that the options module now _only_ looks at the command-line arguments and environment variables. Instead of returning a View, it returns the user's _preference_, and it's then up to the 'main' module to examine the terminal width and figure out if the view is doable, downgrading it if necessary.
The code that used to determine the view was horrible and I'm pleased it can be cut out. Also, the terminal width used to be in a lazy_static because it was queried multiple times, and now it's not in one because it's only queried once, which is a good sign for things going in the right direction.
There are also some naming and organisational changes around themes. The blanket terms "Colours" and "Styles" have been yeeted in favour of "Theme", which handles both extensions and UI colours. The FileStyle struct has been replaced with file_name::Options, making it similar to the views in how it has an Options struct and a Render struct.
Finally, eight unit tests have been removed because they turned out to be redundant (testing --colour and --color) after examining the tangled code, and the default theme has been put in its own file in preparation for more themes.
2020-10-22 21:34:00 +00:00
|
|
|
|
match (mode, self.console_width) {
|
|
|
|
|
(Mode::Grid(ref opts), Some(console_width)) => {
|
2020-10-23 16:47:13 +00:00
|
|
|
|
let filter = &self.options.filter;
|
|
|
|
|
let r = grid::Render { files, theme, file_style, opts, console_width, filter };
|
2020-10-10 18:49:46 +00:00
|
|
|
|
r.render(&mut self.writer)
|
|
|
|
|
}
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
2020-10-23 22:57:10 +00:00
|
|
|
|
(Mode::Grid(_), None) |
|
|
|
|
|
(Mode::Lines, _) => {
|
2020-10-23 16:47:13 +00:00
|
|
|
|
let filter = &self.options.filter;
|
|
|
|
|
let r = lines::Render { files, theme, file_style, filter };
|
Massive theming and view options refactor
This commit significantly refactors the way that options are parsed. It introduces the Theme type which contains both styling and extension configuration, converts the option-parsing process into a being a pure function, and removes some rather gnarly old code.
The main purpose of the refactoring is to fix GH-318, "Tests fail when not connected to a terminal". Even though exa was compiling fine on my machine and on Travis, it was failing for automated build scripts. This was because of what the option-parsing code was trying to accomplish: it wasn't just providing a struct of the user's settings, it was also checking the terminal, providing a View directly.
This has been changed so that the options module now _only_ looks at the command-line arguments and environment variables. Instead of returning a View, it returns the user's _preference_, and it's then up to the 'main' module to examine the terminal width and figure out if the view is doable, downgrading it if necessary.
The code that used to determine the view was horrible and I'm pleased it can be cut out. Also, the terminal width used to be in a lazy_static because it was queried multiple times, and now it's not in one because it's only queried once, which is a good sign for things going in the right direction.
There are also some naming and organisational changes around themes. The blanket terms "Colours" and "Styles" have been yeeted in favour of "Theme", which handles both extensions and UI colours. The FileStyle struct has been replaced with file_name::Options, making it similar to the views in how it has an Options struct and a Render struct.
Finally, eight unit tests have been removed because they turned out to be redundant (testing --colour and --color) after examining the tangled code, and the default theme has been put in its own file in preparation for more themes.
2020-10-22 21:34:00 +00:00
|
|
|
|
r.render(&mut self.writer)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
(Mode::Details(ref opts), _) => {
|
2020-10-10 18:49:46 +00:00
|
|
|
|
let filter = &self.options.filter;
|
|
|
|
|
let recurse = self.options.dir_action.recurse_options();
|
|
|
|
|
|
|
|
|
|
let git_ignoring = self.options.filter.git_ignore == GitIgnore::CheckAndIgnore;
|
2020-10-13 00:28:42 +00:00
|
|
|
|
let git = self.git.as_ref();
|
2021-05-08 14:37:53 +00:00
|
|
|
|
let r = details::Render { dir, files, theme, file_style, opts, recurse, filter, git_ignoring, git };
|
2020-10-13 00:28:42 +00:00
|
|
|
|
r.render(&mut self.writer)
|
2020-10-10 18:49:46 +00:00
|
|
|
|
}
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
Massive theming and view options refactor
This commit significantly refactors the way that options are parsed. It introduces the Theme type which contains both styling and extension configuration, converts the option-parsing process into a being a pure function, and removes some rather gnarly old code.
The main purpose of the refactoring is to fix GH-318, "Tests fail when not connected to a terminal". Even though exa was compiling fine on my machine and on Travis, it was failing for automated build scripts. This was because of what the option-parsing code was trying to accomplish: it wasn't just providing a struct of the user's settings, it was also checking the terminal, providing a View directly.
This has been changed so that the options module now _only_ looks at the command-line arguments and environment variables. Instead of returning a View, it returns the user's _preference_, and it's then up to the 'main' module to examine the terminal width and figure out if the view is doable, downgrading it if necessary.
The code that used to determine the view was horrible and I'm pleased it can be cut out. Also, the terminal width used to be in a lazy_static because it was queried multiple times, and now it's not in one because it's only queried once, which is a good sign for things going in the right direction.
There are also some naming and organisational changes around themes. The blanket terms "Colours" and "Styles" have been yeeted in favour of "Theme", which handles both extensions and UI colours. The FileStyle struct has been replaced with file_name::Options, making it similar to the views in how it has an Options struct and a Render struct.
Finally, eight unit tests have been removed because they turned out to be redundant (testing --colour and --color) after examining the tangled code, and the default theme has been put in its own file in preparation for more themes.
2020-10-22 21:34:00 +00:00
|
|
|
|
(Mode::GridDetails(ref opts), Some(console_width)) => {
|
2020-10-10 18:49:46 +00:00
|
|
|
|
let grid = &opts.grid;
|
|
|
|
|
let details = &opts.details;
|
|
|
|
|
let row_threshold = opts.row_threshold;
|
2017-10-02 07:45:55 +00:00
|
|
|
|
|
Massive theming and view options refactor
This commit significantly refactors the way that options are parsed. It introduces the Theme type which contains both styling and extension configuration, converts the option-parsing process into a being a pure function, and removes some rather gnarly old code.
The main purpose of the refactoring is to fix GH-318, "Tests fail when not connected to a terminal". Even though exa was compiling fine on my machine and on Travis, it was failing for automated build scripts. This was because of what the option-parsing code was trying to accomplish: it wasn't just providing a struct of the user's settings, it was also checking the terminal, providing a View directly.
This has been changed so that the options module now _only_ looks at the command-line arguments and environment variables. Instead of returning a View, it returns the user's _preference_, and it's then up to the 'main' module to examine the terminal width and figure out if the view is doable, downgrading it if necessary.
The code that used to determine the view was horrible and I'm pleased it can be cut out. Also, the terminal width used to be in a lazy_static because it was queried multiple times, and now it's not in one because it's only queried once, which is a good sign for things going in the right direction.
There are also some naming and organisational changes around themes. The blanket terms "Colours" and "Styles" have been yeeted in favour of "Theme", which handles both extensions and UI colours. The FileStyle struct has been replaced with file_name::Options, making it similar to the views in how it has an Options struct and a Render struct.
Finally, eight unit tests have been removed because they turned out to be redundant (testing --colour and --color) after examining the tangled code, and the default theme has been put in its own file in preparation for more themes.
2020-10-22 21:34:00 +00:00
|
|
|
|
let filter = &self.options.filter;
|
2020-10-10 18:49:46 +00:00
|
|
|
|
let git_ignoring = self.options.filter.git_ignore == GitIgnore::CheckAndIgnore;
|
2020-10-13 00:28:42 +00:00
|
|
|
|
let git = self.git.as_ref();
|
Massive theming and view options refactor
This commit significantly refactors the way that options are parsed. It introduces the Theme type which contains both styling and extension configuration, converts the option-parsing process into a being a pure function, and removes some rather gnarly old code.
The main purpose of the refactoring is to fix GH-318, "Tests fail when not connected to a terminal". Even though exa was compiling fine on my machine and on Travis, it was failing for automated build scripts. This was because of what the option-parsing code was trying to accomplish: it wasn't just providing a struct of the user's settings, it was also checking the terminal, providing a View directly.
This has been changed so that the options module now _only_ looks at the command-line arguments and environment variables. Instead of returning a View, it returns the user's _preference_, and it's then up to the 'main' module to examine the terminal width and figure out if the view is doable, downgrading it if necessary.
The code that used to determine the view was horrible and I'm pleased it can be cut out. Also, the terminal width used to be in a lazy_static because it was queried multiple times, and now it's not in one because it's only queried once, which is a good sign for things going in the right direction.
There are also some naming and organisational changes around themes. The blanket terms "Colours" and "Styles" have been yeeted in favour of "Theme", which handles both extensions and UI colours. The FileStyle struct has been replaced with file_name::Options, making it similar to the views in how it has an Options struct and a Render struct.
Finally, eight unit tests have been removed because they turned out to be redundant (testing --colour and --color) after examining the tangled code, and the default theme has been put in its own file in preparation for more themes.
2020-10-22 21:34:00 +00:00
|
|
|
|
|
|
|
|
|
let r = grid_details::Render { dir, files, theme, file_style, grid, details, filter, row_threshold, git_ignoring, git, console_width };
|
|
|
|
|
r.render(&mut self.writer)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
(Mode::GridDetails(ref opts), None) => {
|
|
|
|
|
let opts = &opts.to_details_options();
|
|
|
|
|
let filter = &self.options.filter;
|
|
|
|
|
let recurse = self.options.dir_action.recurse_options();
|
|
|
|
|
let git_ignoring = self.options.filter.git_ignore == GitIgnore::CheckAndIgnore;
|
|
|
|
|
|
|
|
|
|
let git = self.git.as_ref();
|
2021-05-08 14:37:53 +00:00
|
|
|
|
let r = details::Render { dir, files, theme, file_style, opts, recurse, filter, git_ignoring, git };
|
2020-10-13 00:28:42 +00:00
|
|
|
|
r.render(&mut self.writer)
|
2016-10-29 18:07:43 +00:00
|
|
|
|
}
|
|
|
|
|
}
|
2014-06-21 17:12:29 +00:00
|
|
|
|
}
|
2014-07-05 21:36:43 +00:00
|
|
|
|
}
|
Inline the library into the binary
This commit removes the library portion of exa. Cargo now only builds a binary.
The original intent was for exa to have its own internal library, and have the binary just call the library. This is usually done for code cleanliness reasons: it separates the code that implements the purpose of the program (the "plumbing") from the code that the user interacts with (the "porcelain"), ensuring a well-defined interface between the two.
However, in exa, this split was in completely the wrong place. Logging was handled in the binary, but option parsing was handled in the library. The library could theoretically print to any Writer ("for testing", it said), but it's far easier to run integration tests by executing the binary than to change the code to handle unit tests, so this abstraction isn't gaining us anything.
I've also had several people ask me if exa should be packaged for Linux distributions as a library, or just a binary. Clearly, this is confusing!
In several of my other Rust projects, I've done this better, with the command-line option parsing and log printing done on the binary side. It also turns out that you don't need to have a [lib] section in the Cargo.toml, so that's gone too.
2020-10-10 00:43:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mod exits {
|
|
|
|
|
|
|
|
|
|
/// Exit code for when exa runs OK.
|
|
|
|
|
pub const SUCCESS: i32 = 0;
|
|
|
|
|
|
|
|
|
|
/// Exit code for when there was at least one I/O error during execution.
|
|
|
|
|
pub const RUNTIME_ERROR: i32 = 1;
|
|
|
|
|
|
|
|
|
|
/// Exit code for when the command-line options are invalid.
|
|
|
|
|
pub const OPTIONS_ERROR: i32 = 3;
|
|
|
|
|
}
|