Commit Graph

14 Commits

Author SHA1 Message Date
Benjamin Sago f8df02dae7 Batch source formatting
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
2020-10-10 20:02:55 +01:00
Benjamin Sago c3c39fee0a Various misc clippy fixes 2020-10-10 15:57:40 +01:00
Benjamin Sago 70a30ed683 The Selfening
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.
2020-10-10 13:55:26 +01:00
Thibaut Brandscheid 755876e9b6 fix most clippy warnings 2018-06-19 17:17:39 +02:00
quininer kel 0828133300 Fix TextCellContents cjk width 2017-05-10 16:26:50 +08:00
Benjamin Sago 4335f1978c Low-hanging clippy fruit 2017-05-07 17:15:22 +01:00
Benjamin Sago cac80410c9 Extract method for making a cell from its contents 2017-05-02 18:16:21 +01:00
Benjamin Sago a53c268c54 Measure, rather than calculating, cell widths
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.
2017-05-01 14:11:16 +01:00
TSUYUSATO Kitsune e81b83b4ac Implement -F/--classify option 2017-04-14 07:27:37 +09:00
Benjamin Sago c009a68ae5 Add Add impl and various tests for DisplayWidth 2016-04-05 18:45:35 +01:00
Benjamin Sago 15cd67abe6 Turn TextCellContents into a struct
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.
2015-12-17 17:51:42 +08:00
Benjamin Sago 39aa210437 Rename cell 'length' to 'width'
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)
2015-12-17 10:34:11 +08:00
Benjamin Sago 4c2bf2f2e6 Encapsulate "display width" in a struct
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.
2015-12-17 10:15:09 +08:00
Benjamin Sago c911b5f6e4 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 08:25:20 +08:00