We forked this library and therefore have never really considered the API from the ground up. Now, I think there are some improvements that could be made.

As a reference, here is the current API: https://docs.rs/uutils_term_grid/0.3.0/term_grid/index.html

To create a grid, we need to go through several steps:

1. Create a GridOptions
2. Create a Grid
3. Add items to the Grid
4. Fit the Grid to a width (or number of columns) to get a Display
5. Print the Display.

There are a couple of problems with this:

• It's a lot of steps
• The options of the grid are artificially divided into the GridOptions and the width.
• Add items have to be added individually.
• Display is poorly named.

So, here's what we could do:

let items = vec!["a.txt", "b.txt", ...];
let options = GridOptions {
    direction: ...,
    filling: ...,
    width: ...,
};
let grid = Grid::new(items, options);

The only problem with that is the width calculations, which are currently off, because of the ANSI color codes that are not ignored by the unicode-width crate (and it shouldn't do that because that's not really what it's for, see unicode-rs/unicode-width#24). So, we still need some way to pass with widths manually. That could be done fairly easily like so:

let grid = Grid::new_with_widths(items, widths, options);

Note that this again differs from the current API, because currently we deal with pairs of the string and width. This hurts cache-locality and makes it harder to do computations with the widths (which is what much of this crate boils down to under the hood). Changing that might therefore also have a positive effect on performance.

Alternatively, we always require the widths, because neither uutils nor eza are using the built-in width calculations.