I have yet to test if this actually improves performance in Rust. If it does, this commit should close #5. This isn't exactly the best code in the world, so you might want to improve on it.

If you only add one string to the grid, it will fail and return None. Here is the example code:

extern crate term_grid;
use term_grid::{Grid, GridOptions, Direction, Filling};

fn main() {
    let mut grid = Grid::new(GridOptions {
        direction:  Direction::TopToBottom,
        filling:    Filling::Spaces(2),
    });

    for i in 0..1 {
        grid.add(format!("{}", 2_isize.pow(i)).into())
    }

    if let Some(grid_display) = grid.fit_into_width(40) {
        println!("{}", grid_display);
    }
    else {
        println!("Couldn't fit grid into 40 columns!");
    }
}

This patch provides some minor improvements and the use of more idiomatic Rust in some areas of the code. IMHO it makes the code easier to understand 😄

See the following commit in my (rather poor) Python implementation of this algorithm: ArniDagur/guide-key.nvim@fbd9b5e

As you can see, I tried both binary search and looping downwards from the theoretical maximum number of lines, to 1. Both seemed to improve performance, but there are almost certainly better ways to go about it.

I thought about basing binary search hi/lows off of the theoretical maximum number of lines, but the problem there is that I'm not sure how to efficiently calculate the theoretical minimum. This occurs when the items are sorted from highest to lowest (or the other way around).

@ogham I would love to hear your ideas and thoughts.

Hi! I'm reviewing this crate for inclusion in Fuchsia, and our dependency tooling works best when there's a LICENSE file in the root of the crate upload, see regex for an example.

The currently published version of this crate seems to exclude the license from the tarball: https://docs.rs/crate/term_grid/latest/source/Cargo.toml.orig, but I'm not seeing the equivalent on HEAD: https://github.com/ogham/rust-term-grid/blob/master/Cargo.toml#L7.

Would it be possible to publish an updated version of the crate based on the current tip-of-tree? Thanks!

https://github.com/ogham/rust-term-grid/blob/1cbc10f4fd641e49c20e72afbad3f850af51ab61/src/lib.rs#L319

For this line of code, it will always update the value of widths[index], even if the value of it does not change. This introduces some redundant operations.

If we change the code to this, we can eliminate these redundant operations.

if widths[index] < cell.width{
     widths[index] = cell.width;
}

According to my tests, the average execution time decreased from 6.5s to 4.8s, which is a 1.37x speedup.

Hope this information helps!

These changes were initiated to fix the behavior of term-grid in uutils's ls, which uses term-grid 0.1.7 but can't upgrade to 0.2.0 due to the existence of these bugs.

Ideally, I'd like to upgrade to 0.2.0, offloading a lot of padding/alignment code to term-grid instead.

Things I've taken care of:

• Fixed loop boundaries.
• Allowed grid to try to utilize the maximum width it can, optimizing for line-count.

Things I've not taken care of, yet:

• I didn't create a test to make sure this behavior does not regress.
• I didn't fix the other bug where terminal color-codes ruin the width calculation.

uutils's ls --color re-calculates widths, passing them explicitly to cells, because terminal colors ruin the width calculation of term-grid.

Ideally, term-grid should recognize color escape sequences and treat them as zero-width, or at least have a grid option which makes that possible, to allow out-of-the-box color handling.

Closes https://github.com/ogham/rust-term-grid/issues/11

Hi! Thanks for this great library! Like I mentioned in the issue, we would love to upgrade to a later version, but this is blocking us, so I thought I would implement it in a PR. It contains exactly the change in the issue.