• Bring what's shown in the version string in line with my other projects (URL, description, git hash and date for release-mode non-final builds only, potential for colours in the future)
• Show +git or -git depending on feature status
• Tests for the above, and for checking that the command-line flag is warned about
• The spaces between icons and filenames are now coloured too
• Some icons are different
• File sizes are now more accurate
• New help text, which needed a newline at the end
The flags --git and --git-ignore are caught early during options parsing, so no more checking for git feature is done elsewhere.
Since --git-ignore depends on git too since recently, remove it from help when git feature is disabled.
Extended attributes now don’t artificially depends on git feature being enabled.
This commit remove the extra space that was added between icons and file names in commit 128fadd, and adds an option to put them back.
Re-fixes GH-619 and fixes GH-541.
All four of the view mode command-line argument parsers tested for the --icons option. Because it was common, the behaviour has been moved to the struct that handles file styles, meaning it can be parsed in one place.
This is a better place for it, as the icons are to do with the file name, not the view. It also means that the lines view has no options left for it, which is fitting.
This commit changes the way the View (long mode, lines mode, grid mode, etc) is parsed from the command-line arguments.
Previously, it checked for long and long-grid, then tree, then lines, then grid, in that order, no matter which order the arguments were given in on the command-line. Now, it bases the view on whichever argument comes last in the list.
Unfortunately, the options-parsing code for Views is getting really complicated, but I can't see a way to simplify it while retaining the existing functionality.
It also links the parsing of DirAction to the result of parsing the View, so that you can't use tree mode if your view isn't Details. This is to fix an issue where `exa --tree --oneline` would just emit ".", because the DirAction was treating directories as files, and the argument was ".", and the View made it use lines view. Now, the --tree is ignored, as the view isn't Details.
Fixes GH-407 and GH-583.
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.
This changes the --help text, and gets rid of the special behaviour for --help --long, which I thought was a really good idea at the time, but now I just think it's inconsistent and unexpected behaviour. --help should return the same help, no matter what other arguments you have typed.
Other things:
• Put --help and --version in a section
• Capitalisation consistency
• Alignment
• Move the --octal-permissions line up a bit
• Simplify the printing implementation (HelpString is now a unit struct)
This _finally_ makes all the extended tests pass.
This commit fixes a couple of Clippy warnings, and adds the list of lints we're OK with.
It does raise some important warnings, such as those to do with casting, which aren't allowed so they can be fixed later.
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.
I read through every file and applied a couple of rustfmt suggestions. The brace placement and alignment of items on similar lines has been made consistent, even if neither are rustfmt's default style (a file has been put in place to enforce this). Other changes are:
• Alphabetical imports and modules
• Comma placement at the end of match blocks
• Use newlines and indentation judiciously
• Spaces around associated types
• Spaces after negations (it makes it more clear imho)
• Comment formatting
• Use early-returns and Optional `?` where appropriate
These are holdovers from how I used to write Rust ("back in the day" of 2014). There are still some places in the code where I think it's worth glob-importing enums, but not these places.
This commit makes changes to the way variables are referenced:
• Make types Copy when possible
• Make methods take `self` instead of `&self` where possible (trivially_copy_pass_by_ref)
• Remove unnecessary borrowing (needless_ref)
• Remove unnecessary cloning (clone_on_copy)
• Remove `ref` from match arms where possible (new Rust match ergonomics)
This commit uses Clippy to fix all the 'use_self' warnings. Using Self instead of the type name has been good Rust style for a while now, and it's become the style I'm used to seeing.
This commit removes the env_logger dependency, replacing it with a simple implementation. Doing so removes like ten other transitive dependencies that no longer need to be included in the build.
It also gains the ability to enable trace-level logging. The users crate, which contains such logging statements as of the version I published a few days ago, has been upgraded to celebrate.
Also, change the log imports to globs. I'm only interested that a file doing logging, not what level it's logging at.
Using --octal_permissions will insert another column before the existing
permissions where permissions are encoded using octal values as
requested in #316
