The arguments passed to File’s constructor were different from the field names used — these might as well both be the same.
Also, move ext and filename to be File methods to save an import, and add tests.
Also also, by passing a PathBuf in to the constructor directly, we can save one (possibly two) instance/s where we pass in a reference to something we were going to lose ownership of anyway, only to have it basically cloned.
There’s a problem with the tree view where it’ll still recurse through `.` and `..`. But if you were using tree view, would you even need to see them? They’d be in the tree already!
There was a problem when displaying . and .. in directory listings: their names would normalise to actual names! So instead of literally seeing `.`, you’d see the current directory’s name, inserted in sort order into the list of results. Obviously this is not what we want.
In unrelated news, putting `.` and `..` into the list of paths read from a directory just takes up more heap space for something that’s basically constant.
We can solve both these problems at once by moving the DotFilter to the files iterator in Dir, rather than at the Dir’s creation. Having the iterator know whether it should display `.` and `..` means it can emit those files first, and because it knows what those files really represent, it can override their file names to actually be those sequences of dots.
This is not a perfect solution: the main casualty is that a File can now be constructed with a name, some metadata, both, or neither. This is currently handled with a bunch of Options, and returns IOResult even without doing any IO operations.
But at least all the tests pass!
I originally thought that the entries . and .. were in *every* directory entry, and exa was already doing something to filter it out. And then... I could find no such code! Turns out, if we want those entries present, we have to insert them ourselves.
This was harder than expected. Because the file filter doesn’t have access to the parent directory path, it can’t “filter” the files vector by inserting the files at the beginning.
Instead, we do it at the iterator level. A directory can be scanned in three different ways depending on what sort of dotfiles, if any, are wanted. At this point, we already have access to the parent directory’s path, so we can just insert them manually. The enum got moved to the dir module because it’s used most there.
If a function returns one of several enum variants, but we’re only interested in one, then just return its contents and have it apply the Mode “wrapper” later.
These two fields were originally needed to determine how to recurse when using tree view.
However, as there was no distinction between the “options parsed from the command-line” Details and the “values needed to render a table” Details, these had to be threaded through the options parser as a special-case to end up in the right struct.
No more! Because there are separate structs for options and rendering, we can just add them in later.
Instead of having render methods on the types that are now called Options, create new Render structs (one per view) and execute them. This means that it’s easier to extract methods from them — some of them are pretty long.
Also, remove the GridDetails struct, which got consumed by Mode (mostly)
By introducing another indirection between the structs that command-line options get parsed into and the structs that get rendered, it should be easier to refactor that horrible function in view.rs.
Now that colours don’t depend on a previously-calculated “should we be using colours” boolean anymore, their entire deduce function can be done separately to the mode’s one.
exa assumed that the COLUMNS environment variable being present always meant that the output was to a terminal, so it should use colours. But because this variable can be overridden, colours were being incorrectly set!
The ‘fix’ is to stop trying to be clever while only calculating the terminal width once, and instead just stick it in a lazy_static so it’s usable everywhere.
All four view types — lines, grid, details, and grid-details — held their own colours and classify flags.
This didn’t make any sense for the grid-details view, which had to pick which one to use: the values were in there twice.
It also gave the Table in the details view access to more information than it really should have had.
Now, those two flags are returned separately from the view “mode”, which is the new term for one of those four things.
Unlike the others, setuid/setgid/sticky get merged with user/group/other execute in the rendered Permissions cell. So there had to be a bit of code change done to make sure that none of the bits clashed.
The problem here was that we were using `metadata.permissions().mode()`, which is capped at 0o777, rather than `metadata.mode()`, which exposes every bit. With this change, we can access the higher-order permission bits, and put them in the Permissions struct.
On the plus side, this removes some imports from details, and makes the file shorter. On the minus side, the ‘render timestamp’ function has a hell of a signature.
The three pieces of information for the leftmost details view column (file type, permissions, and whether xattrs are present) used to be gathered from separate sources and passed around separately before being displayed at the end. Now, file type and permissions are put into a struct, along with the xattrs boolean that’s still getting passed around all over the place but not quite as much.
This was all done because I wanted to be able to test permissions rendering, without having file type and xattrs dragged into the same function.
A field can now render itself using colours and a users reference, rather than a Table doing the rendering. This way, only the relevant fields in the Environment can be made available to the render function, and the test code loses some lines.
Override the size column for block and charater devices, so it shows the major and minor device IDs instead (which are in the Metadata struct somewhere).
This is what ls does when faced with a device.
By parsing OsStrings rather than Strings, it’s the getopts crate that’s doing the UTF-8 checking rather than us, so if one of them isn’t valid, it’ll just fail to parse rather than crash exa.
Also, save a few allocations here and there.
This makes it possible to use them in scripts. Also, I couldn’t find any other program returned a different error code! So it’s being changed to 0.
Fixed#180.
Fixes#134, a bug that showed symlinks incorrectly as broken, but only when the file was listed directly on the command-line *and* the file was in a different directory to the one exa was being run in.
I’m not sure why the old code used `String::new()`, but it doesn’t seem to affect anything.
Because the link style and status are now both available to the function that picks the colour style, we can have it highlight broken links differently.
Fixes#131.
The old option descriptions were all written at different times, and needed some consistency. This makes everything consistent between the help text, README, man page, and shell completions, and fixes some mistakes made when writing them.
This also adds the missing options to the man page, fixing #175.
We already use MetadataExt and PermissionsExt, so it already requires a Unix system — there’s no point providing fallback implementations if it wouldn’t build on those systems anyway.
For some reason, the code that calculated the width of a cell with a path in counted the width of the path twice: once from the ANSIStrings containing it, and once more added on afterwards. This meant that the grid view thought that columns were wider than they really were, meaning fewer could be fit into a grid.
Doing this meant that the escaping functionality got used in three places, so it was extracted into a generalised function in its own module.
This is slighly slower for the case where escaped characters are displayed in the same colour as the displayable characters, which happens when listing a directory’s name when recursing. Optimise this, yeah?
This turns `file` into `self.file` and `colours` into `self.colours`, but it means we don’t need to pass arguments everywhere, which will be more of a problem the more functions there are.
Most of the code has just been indented.
Rather than the *entire* file name.
The current method is extremely inefficient, but having control characters in file names is also extremely uncommon; it’s something that should be fixed, only eventually.
exa deals with cells and widths a lot: the items in a grid need to be aligned according to their *contents’* widths, rather than the length of their strings, which often included ANSI escape characters. As an optimisation, it used to calculate this separately based on the filename, and dealing with any extra characters (such as the classify ones) in that function too.
Recently, though, file names have become a lot more complicated. Classification added zero to one extra characters, and now with escaped control characters in file names, it’s not so easy to calculate the display width of a filename.
This commit removes the function that calculated the width, in favour of building the output string (it’s going to be displayed anyway) and just getting the width of what it displays instead.
It's confusing, and `ls` doesn't do this either. We're not prepending
the current path to all of the directory entries, and the user is going
to interpret the symlink target as relative to the directory containing
the symlink.
It’s the only file where its path is the same as its file name, and has been the source of numerous bugs in the past… this special-case isn’t very clean, but it works.
This adds an option (always on at the moment) to use a colour scale of green to yellow to orange for the file size field instead of always green. See #65.
This makes the Colours value pick a colour based on the size of the file, instead of necessarily having them all green. (They are all green for now, though.)
See #97 and recently #130 too.
This allows the user to pass in options such as "--ignore '*.pyc'" to not list any files ending in '.pyc' in the output. It uses the Rust glob crate and currently does a simple split on pipe, without any escaping, so it’s not really *complete*, but is at least something.
Fixes#123. The code assumes that every File that has its link_target() method called would first have been checked to make sure it’s actually a link first. Unfortunately it also assumed that the only thing that can go wrong while following a link is if the file wasn’t a link, meaning it crashes when given a link it doesn’t have permission to follow.
This makes the file_target() method able to return either a file or path for displaying, as before, but also an IO error for when things go wrong.
This changes the way that views are used to display the actual lists of files. It used to pass empty vectors to the view methods, which most of the time would not print anything because there are no files to list — except when there’s a header row which gets printed for no files.
By not calling the view method at all when there’s nothing to print, exa won’t ever print extra things in the view unless it needs to for a file.
This fixes#106 “Don’t print the header if the result set is empty”
Now when you do `--sort time` instead of saying "unknown option --sort
time" it will say "unknown options '--sort time' (choices: name...)"
with all legal options.
This also adds the legal values to the default help text.
This commit removes the 'main' function present in main.rs, renames it to exa.rs, and puts the 'main' function in its own binary. This, I think, makes it more clear how the program works and where the main entry point is.
Librarification also means that we can start testing as a whole. Two tests have been added that test everything, passing in raw command-line arguments then comparing against the binary coloured text that gets produced.
Casualties include having to specifically mark some code blocks in documentation as 'tests', as rustdoc kept on trying to execute my ANSI art.
The original options was becoming a bit unwieldy, and would have been even more so if I added the same amount of comments. So this commit splits it up.
There's no extra hiding going on here, or rearranging things within the module: (almost) everything now has to be marked 'pub' to let other sub-modules in the new options module to see it.
The trait was only used internally to the options module, so it doesn't actually need to be exist or implemented on anything! We can just impl them directly on the types and have those methods be local to the module.
This commit moves file, dir, and the feature modules into one parent 'fs' module. Now there are three main 'areas' of the code: main and options, the filesystem-touching code, and the output-displaying code.
It should be the case that nothing in 'output' touches 'std::fs'.
Fixes#108. MetadataExt now returns direct numeric types rather than platform-specific ones, so we need to adjust the functions that use these to have the new types. I've just aliased the types to specific ones so the rest of the code remains the same (file.rs is the only place that uses this)
The RFC that changed this is here: https://github.com/rust-lang/rust/pull/31551
This commit changes all the views to accommodate printing each path's prefix, if it has one.
Previously, each file was stripped of its ancestry, leaving only its file name to be displayed. So running "exa /usr/bin/*" would display only filenames, while running "ls /usr/bin/*" would display each file prefixed with "/usr/bin/". But running "ls /usr/bin/" -- without the glob -- would run ls on just the directory, printing out the file names with no prefix or anything.
This functionality turned out to be useful in quite a few situations: firstly, if the user passes in files from different directories, it would be hard to tell where they came from (especially if they have the same name, such as find | xargs). Secondly, this also applied when following symlinks, making it unclear exactly which file a symlink would be pointing to.
The reason that it did it this way beforehand was that I didn't think of these use-cases, rather than for any technical reason; this new method should not have any drawbacks save making the output slightly wider in a few cases. Compatibility with ls is also a big plus.
Fixes#104, and relates to #88 and #92.
This fixes a bug where extra sorting options (dirs first, reverse) were not applied when listing in long mode. In other words, fixes#105.
The bug occurred because the sorting function only took Files, but the details view uses File eggs that only contain Files. This commit changes the sorting function to accept anything that AsRefs to File, and impls that on both File and Egg so the same function works for both.
Thinking about it, it doesn't make sense to use an *external* time zone source when the program we want to compare it to, ls, uses the system one. So just use the system one.
Also, handle the case where the time zone data file can't be loaded by showing the files in UTC rather than falling over and quitting.
This uses the case-insensitive sort function in the `natord` crate to
convert both strings to lowercase lazily, sorting them as it goes. It
also adds tests for `--sort` in general.
The case sensitivity has been made an enum so it can be reused for other
fields (say, the file extension).
See #102.
- Fix visibility errors I stupidly didn't test before committing earlier
today
- Silence warnings about casting that were necessary for ARM
- Update dependencies
Something about these seemed to be causing a crash on Travis (build 327)... I have no idea what would set it off, but this makes the code better anyway.
- Users v0.5.1, which renames OSUsers to UsersCache
- Locale v0.2, which returns to libc v0.1
- Datetime v0.4.2, which mimics the locale update, and puts timezone definitions in:
- Zoneinfo-data, which is needed to obtain the current timezone
The `--long` flag should show the '@' character in the permissions list if that feature has been compiled in, but only the `--extended` flag should actually show their keys, rather than just their presence.
This makes use of a change in the `users` crate to change which parts of exa's code are accessed under a `Mutex`. The change is that the methods on `Users` can now take just `&self`, instead of `&mut self`. This has a knock-on effect in exa, as many methods now don't need to take a mutable `&self`, meaning that the Mutex can be moved to only containing the users information instead of having to be queried for *every column*. This means that threading should now be a lot faster, as fewer parts have to be executed on a single thread.
The main change to facilitate this is that `Table`'s structure has changed: everything environmental that gets loaded at the beginning is now in an `Environment` struct, which can be mocked out if necessary, as one of `Table`'s fields. (They were kind of in a variety of places before.)
Casualties include having to make some of the test code more verbose, as it explicitly takes the columns and environment as references rather than values, and those both need to be put on the stack beforehand. Also, all the colours are now hidden behind an `opts` field, so a lot of the rendering code is more verbose too (but not greatly so).
This commit separates the code used to generate the tree structure characters from the code used to build tables, meaning that it'll become possible to display tree structures without using any of the table code.
Also, some tests are added to make sure that the tree code *basically* works.
This commit moves the colours module to be a sub-module of the output one.
This makes sense because finding which colour a certain file should be is only
done during output, and (I think) the only places that the `Colours` struct's
fields are ever queried is from the output module.
The only casualty was that the `file_colour` from the filetype module had to
be moved, as determining colours is no longer part of that module - only
determining filetype is. So it now reflects its name!
The benefit of this is that it make it possible to convert text cell contents
vectors into text cells with a method (see next commit). Casualties include
having to call `.into()` on vectors everywhere, which I'm not convinced is a
bad thing.
Because, strictly speaking, it's not a length, it's a width!
Also, re-order some struct constructors so that they're no longer
order-dependent (it's no longer the case that a value will be borrowed for one
field then consumed in another, meaning they have to be ordered in a certain
way to compile. Now the value is just worked out beforehand and the fields can
be specified in any order)
By removing the `File#file_name_width` method, we can make the file module
have no dependency on the output module -- in other words, the model (file)
and the view (output) are now separate again!
This commit introduces the `output::cell::DisplayWidth` struct, which
encapsulates the Unicode *display width* of a string in a struct that makes it
less easily confused with the *length* of a string.
The use of this type means that it's now harder to accidentally use a string's
length-in-bytes as its width. I've fixed at least one case in the code where
this was being done!
The only casualty is that it introduces a dependency on the output module from
the file module, which will be removed next commit.
A recent change to ansi-term [1] means that `ANSIString`s can now hold either
owned *or* borrowed data (Rust calls this the Cow type). This means that we
can delay formatting ANSIStrings into ANSI-control-code-formatted strings
until it's absolutely necessary. The process for doing this was:
1. Replace the `Cell` type with a `TextCell` type that holds a vector of
`ANSIString` values instead of a formatted string. It still does the
width tracking.
2. Rework the details module's `render` functions to emit values of this
type.
3. Similarly, rework the functions that produce cells containing filenames
to use a `File` value's `name` field, which is an owned `String` that
can now be re-used.
4. Update the printing, formatting, and width-calculating code in the
details and grid-details views to produce a table by adding vectors
together instead of adding strings together, delaying the formatting as
long as it can.
This results in fewer allocations (as fewer `String` values are produced), and
makes the API tidier (as fewer `String` values are being passed around without
having their contents specified).
This also paves the way to Windows support, or at least support for
non-ANSI terminals: by delaying the time until strings are formatted,
it'll now be easier to change *how* they are formatted.
Casualties include:
- Bump to ansi_term v0.7.1, which impls `PartialEq` and `Debug` on
`ANSIString`.
- The grid_details and lines views now need to take a vector of files, rather
than a borrowed slice, so the filename cells produced now own the filename
strings that get taken from files.
- Fixed the signature of `File#link_target` to specify that the
file produced refers to the same directory, rather than some phantom
directory with the same lifetime as the file. (This was wrong from the
start, but it broke nothing until now)
References:
[1]: ansi-term@f6a6579ba8174de1cae64d181ec04af32ba2a4f0
src/feature/xattr.rs:6:5: 6:22 warning: unused import, #[warn(unused_imports)] on by default
src/feature/xattr.rs:6 use std::ffi::CString;
^~~~~~~~~~~~~~~~~
The buggy code assumed that, if output isn't to a terminal, then the only view available is the Lines view. This is incorrect, as the Details view doesn't require a set width either, so check for --long even when there's no set width.
One of those two date formats was re-compiled before any date was displayed. Now they are compiled only the first time they're used, and cached versions are used thereafter, resulting in a speedup.
Instead of using the getopts crate’s dynamically-generated usage string, use a more static one:
- The options are organised by category now
- You can use `--help --long` to display only the ones that pertain to `--long`
- They’re aligned in a table sort of way
It could be generated statically, because all the options to change it are determined at compile time, but they’re not, yet...
Technically speaking, picking which timestamp to show for a file is a function of an output module, rather than the file itself. This also means that the `output::column` and `file` modules are now completely separate.
By taking the file names as a mutable vector, we can avoid having to allocate a new one when it’s empty. The recent changes to Options::getopts have made it more obvious that we could move the same vector out of getopts’s matches, instead of cloning it there.
This cleans up the options module, moving the structs that were *only* in use for the columns view out of it.
The new OptionSet trait is used to add the ‘deduce’ methods that used to be present on the values.
Changes to the way ANSIStrings work mean we need to dereference the strings before putting them in an ANSIString. There's more that can be done here, but this gets it to compile for now.
this commit fixes below type mismatch error:
```
src/output/details.rs:585:49: 585:60 error: mismatched types:
expected `i64`,
found `i32`
(expected i64,
found i32) [E0308]
src/output/details.rs:585 let date = self.tz.at(LocalDateTime::at(timestamp.0));
^~~~~~~~~~~
src/output/details.rs:585:49: 585:60 help: run `rustc --explain E0308` to see a detailed explanation
error: aborting due to previous error
Could not compile `exa`.
```
The `unused_results` lint was complaining that the results of inserting into a `MockUsers` object weren't being inspected. These are mock users, so all that would be returned is `None` to indicate that they weren't already in the table -- they're fine to ignore! So, suppress the warnings for those two testing modules.
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 :)
Had to thread the value in at display-time to get it to only query the attributes once!
This isn't the nicest way to do it, but this *is* a bit of an edge-case (it's the only thing where a column depends on something that gets calculated later)
This prints three separate groups of child nodes: firstly the xattrs, then the errors, then any file children. It's done this way to only check for the 'last' child when necessary.
This does a similar thing that we did with the xattrs, except with the nested files: it removes the 'this' field on File, and replaces it with a method (to_dir) that has the same effect.
This means we get to remove a bunch of 'recurse' fields and parameters that really had no business being there! Now the table doesn't need to know whether it's going to need to list files recursively or not.
This changes the way extended attributes (xattrs) are printed. Before, they were artificially printed out on their own line both in lines mode *and* details mode, which looked a bit weird. Now, they are additional 'child nodes' of that item that get printed alongside errors.
All this allows all the 'extra info' that is going to be present for very few entries to be consolidated and listed in the same way, without resorting to extra printlns.
As a great side-effect, it allows taking out some of the more redundant code in the Table impl -- it is now *always* going to be in create-child-nodes mode, as *any* file now can, not only when we have the --tree flag in use.
Also, it now actually displays errors when failing to read the extended attributes, such as if the user doesn't have permission to read them.
The extended attribute flag has been temporarily disabled while I work out the best way to do it!
Now we have one Ur-module that contains functionality common to both supported platforms.
The benefits of doing it this way are that:
1. It doesn't implement a dummy interface - rather, there will be less code generated when the feature is not present;
2. The code shared between them can be kept in sync. The other two modules were something like 80% the same.
When tree mode is active, this will print out errors as another form of child node in the tree, instead of in one big block before any output.
The 'this' field now holds the io::Result of the readdir call, rather than only a *successful* result.
This is part of work to make the flow of files more iterator-able, rather than going in and out of vectors. Here, a Dir returns an iterator of files, rather than a pre-filled vector.
For now, this removes the ability for error messages to be displayed. Will be added in later though!
This is very slow (see #28) at the moment, so there's an option to switch off repo discovery. However, they were still always being queried. Now, if there's no Git option in the flags, it won't try to discover a repo.
These replace `init()` and `tail()` which are deprecated in favour of these.
In fact, it's a good thing they're deprecated, because part of the path_prefix code involved working around a call to init() that would panic otherwise - doing the same check with an `Option` is much more ergonomic.
Previously, each time it tried to render a table (to check its width), it both re-queried the filesystem and re-formatted the values into coloured strings.
These values are now calculated only once before the table is drawn, and are used repeatedly throughout.
Although it looks as though there's more `clone()`ing going on than before, it used to be recalculating things and storing them as vectors anyway, so the memory would still be used in any case.
This commit adds --grid, which, when used with --long, will split the details into multiple columns. Currently this is just 2 columns, but in the future it will be based on the width of the terminal.
In order to do this, I had to do two things:
1. Add a `links` parameter to the filename function, which disables the printing of the arrow and link target in the details view. When this is active, the columns get way too large, and it becomes not worth it.
2. Change the `print_table` function from actually printing the table to stdout to returning a list of `Cells` based on the table. This list then gets its width measured to calculate the width of the resulting table.
Finally! The benefit of having all the field-rendering code (in details.rs) separate from the value-getting code (in file.rs) is that rendering them can be tested again.
Colours are now disabled when output is not to a terminal. Fixes#53!
This required some internal restructuring - colours are now in their own object that gets passed around everywhere it's needed.
Exa now uses the new IO, Path, and Filesystem libraries that have been out for a while now.
Unfortunately, the new libraries don't *entirely* cover the range of the old libraries just yet: in particular, to become more cross-platform, the data in `UnstableFileStat` isn't available in the Unix `MetadataExt` yet. Much of this is contained in rust-lang/rfcs#1044 (which is due to be implemented in rust-lang/rust#14711), but it's not *entirely* there yet.
As such, this commits a serious loss of functionality: no symlink viewing, no hard links or blocks, or users or groups. Also, some of the code could now be optimised. I just wanted to commit this to sort out most of the 'teething problems' of having a different path system in advance.
Here's an example problem that took ages to fix for you, just because you read this far: when I first got exa to compile, it worked mostly fine, except calling `exa` by itself didn't list the current directory. I traced where the command-line options were being generated, to where files and directories were sorted, to where the threads were spawned... and the problem turned out to be that it was using the full path as the file name, rather than just the last component, and these paths happened to begin with `.`, so it thought they were dotfiles.
This module provides feature-specific implementations, and also dummy implementations for when they aren't supported by the system or OS.
Doing it this way limits all the #[cfg(feature)] annotations, as we can now just include the module or not.
In cases where symlink targets were more than a single directory down,
exa did not print the '/' targets when separating directories, resulting
in the following output:
symlink => dirAdirBdirC/file
Instead of
symlink => dirA/dirB/dirC/file
By adding a '/' character after each component of the filename, this
error is fixed.
The old implementation blindly assumed that a symlink target would have a directory compoment, which the current directory, parent directory, and root directory technically don't have.
Fixes#20.
The logic of the previous version wasn't correct. Also, presuming
natural ordering of full filenames is still reasonable when the
extensions are identical.
The challenge is that the paths returned from libgit2's status listing
are from the perspective of the Git repository and thus effectively
relative to the working tree root, while the other paths we're
manipulating are (potentially) relative to our current working
directory. So, if those two aren't identical (if running from outside
the working tree, or from a subdirectory), the paths won't match up.
A reasonably reliable way around this is to resolve both types of paths
to absolute paths before comparing them. This fixes#15 at a basic
level, anyway.
What still doesn't work: referring to the working tree or one of its
descendants via a symlink. For that, we'd probably need to fully resolve
symlinks in the file path.
(The unwrap_or()'s are messy and will probably just result in missing
status information, but then, what information could you hope to get
without having both a current working directory and a Git working tree?)
Filenames with characters that need multiple bytes in UTF-8, and/or
control characters like combining diacritics, would break the grid.
`StrExt::width` seems to do the right thing, and there's conveniently a
function here (which was otherwise unused) to call that.
These were completely missing because I forgot about them... I added sorting functionality before I added date functionality, but it turns out I didn't even need the datetime library to do this!
However, this implementation feels incomplete. If you sort by the accessed date, it still displays the modified date, so the dates still look out of order. If I were to change the date column for the user, though, then there would still be no header to signify that the column has changed. I'm not sure how to proceed with this, but this is still missing functionality, so in it goes.
This has been mostly done with changes in the datetime crate's suddenly
supporting locales.
It's still important that the user's locale is touched only once and
cached from that point on, so a struct in output::details has been made
public, along with that module. This will change later as that object
gains more and more uses thoughout the codes.
Use the `locale` crate as a dependency to read in the set
thousands-separator character, and pass this to the file size column,
which uses it to add the separators in.
en_GB uses ","
fr_FR uses "" and just displays the numbers in one go.
Add options -u, -U, and -m as shorthand options for displaying different
types of timestamp, not just one. It's possible to have more than one by
specifying more than one of these shorthands, but *not* when used with
--time, as this is only meant to display one at a time.
Using the datetime crate, add an extra column to the --long view that
prints out the modified, accessed, or created timestamp for each file.
Also, let the user pick which one they want to see based on the --time
command-line option.
- Turn the views and main program loop into structs, rather than just as one gigantic function
- Separate views into their own files
The addition of the git column and the tree view meant that a lot of functions now just took extra arguments that didn't seem to fit. For example, it didn't really work to have only one 'view' method that printed out everything, as the different view options now all take different parameters.
FileName was always a special-cased column, as it was assumed to be the last column in the output. Now, it's explicitly marked as such. This allows the hash marks to be placed before the filename, rather than at the start of the line.
There's still a lot to do, but this is actually *something*. The tree hierarchy is displayed using hashes at the start of a line. I want to have it just before the filename, but this will need some changes to the way that columns are handled.
Instead of stripping the ANSI formatting characters from our strings, work out the length without them and use that. This is per-column, but most of them are simple (just the same number of characters in the non-coloured string).
Sometimes, this is really simple: for example, trwxrwxrwx permissions strings are always going to be ten characters long, and the strings that get returned are chock full of ANSI escape codes.
This should have a small benefit on performance.
