feat(table): Multi-column table cells

[stijndcl]

Problem

Table cells cannot currently span across multiple columns:

These	Are	Single	Column
But these are		multi-column

This is often useful when wanting to "group" or "nest" headers:

Benchmark	Rust		JavaScript
	CPU	Memory	CPU	Memory
bench1	5%	5kb	100%	5GB

Solution

Add an option to the Cell struct and take it into account when rendering the table. This means that in a table with N columns, each row can contain anywhere between 1 and N cells.

Additional notes

The specific example above would also require multi-row headers, which is a separate issue out of scope for this one. Multi-col cells are still useful in other contexts as well.

[joshka]

If you no longer want Latta AI to attempt solving issues on your repository, you can block this account.

AI is cool with me (I use a variety of things daily). But I prefer there to be a human in the loop that checks things so they're not wasting my time like this.

[joshka]

Hey there,

It might be nice to see some ideas that you have for how the table API will change to support this. Have you got some ideas you can share?

I'm wary of changing the table implementation too much, as it's fairly complex already, which makes adding more complexity a maintenance burden (mostly in reviewing changes). Perhaps if you're interested in implementing this, consider whether there are any simplifying refactorings that can make this easy to implement and review. Also keep in mind what impact the changes would have on existing users.

One approach we like to suggest for adding more advanced behavior to widgets is to first fork them and use them in your own app with the desired changes to validate that things work correctly (note the MIT license allows you to do this, just keep the copyright notice). You might find that creating a tui-advanced-table crate might be worth considering at some point (similar to the the tui-widget-list crate)

[stijndcl]

Hey @joshka

My idea for the API would be something similar to the current style field. In other words, have the Cell struct take a width field (or span or whatever you'd like to call it). By default set it to 1, and let the new/From<> methods set it to 1 as well. That way it doesn't impact people that don't need it. Add a method width(usize) -> Self that modifies the cell and updates the field internally.

Perhaps you can even support Into<Cell> for (Into<Text>, usize) so users can create a multi-col cell using (content, width).into().

This is basically identical to the current approach for styling for end-users, so shouldn't feel out-of-place, and is completely transparant/non-breaking.

In terms of rendering I am not familiar with the internals of Ratatui so I fear I can't provide much insight there. I can imagine there's some functionality that computes the area of a cell, so that should factor in the width in that case (and the width of the cell border/separator that would've gone in between the cells).