Replace Cells with growable TextCells
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
2015-12-17 00:25:20 +00:00
|
|
|
use ansi_term::ANSIStrings;
|
|
|
|
|
2016-04-16 17:59:25 +00:00
|
|
|
use fs::File;
|
2015-12-20 06:56:57 +00:00
|
|
|
|
2015-05-11 22:28:01 +00:00
|
|
|
use super::filename;
|
2015-12-20 06:56:57 +00:00
|
|
|
use super::colours::Colours;
|
2015-02-05 14:39:56 +00:00
|
|
|
|
2015-06-08 20:33:39 +00:00
|
|
|
|
2015-05-09 22:57:18 +00:00
|
|
|
#[derive(Clone, Copy, Debug, PartialEq)]
|
|
|
|
pub struct Lines {
|
|
|
|
pub colours: Colours,
|
|
|
|
}
|
|
|
|
|
2015-02-05 14:39:56 +00:00
|
|
|
/// The lines view literally just displays each file, line-by-line.
|
2015-05-09 22:57:18 +00:00
|
|
|
impl Lines {
|
Replace Cells with growable TextCells
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
2015-12-17 00:25:20 +00:00
|
|
|
pub fn view(&self, files: Vec<File>) {
|
2015-05-09 22:57:18 +00:00
|
|
|
for file in files {
|
Print the parent path for passed-in files
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.
2016-04-11 18:10:55 +00:00
|
|
|
println!("{}", ANSIStrings(&filename(&file, &self.colours, true)));
|
2015-05-09 22:57:18 +00:00
|
|
|
}
|
2015-02-05 14:39:56 +00:00
|
|
|
}
|
|
|
|
}
|