Various gum table width bugs

[hydrargyrum]

gum table has various width bugs

Width is calculated on header only

% gum table <<< "a,b" <<< "1111111111111111111111111,222222222222222222222222"                
 a  b 
 …  … 

Since a table has aligned data, gum already needs to read the whole input. Why does gum only use the header text to determine the width of cells by default? It could use the max width of each text column, (perhaps conditionnally to fit the terminal). But the default is not very good.

cell.width still truncates cell text

% gum table <<< "a,b" <<< "1111111111111111111111111,222222222222222222222222" --cell.width=20
 a  b 
 …                   …                  

why does gum print … though there are ~20 empty space characters that could display the 11111… and 22222…?

cell.width does not affect header

% gum table <<< "a,b" <<< "1111111111111111111111111,222222222222222222222222" --cell.width=20
 a  b 
 …                   …                  

resulting in broken alignment between cells and header

Desktop (please complete the following information):

• OS: debian
• Version https://github.com/charmbracelet/gum/releases/tag/v0.9.0

[MikaelFangel]

Some of the issues you're having with the widths are easily solved by using -w20,20 instead of --cell.width=20.

From the man page:

-w, --widths=WIDTHS,...

Hope it helps.

[hydrargyrum]

Indeed that fixes the unaligned headers, and the data is not truncated anymore!

But:

• default width is still computed only on the header text, which is not very nice IMHO, it can't be used on generic CSV files, it forces you to know in advance the max width of each column
• why can --cell.width produce such inconsistent behavior? What's the use case of doing so? Maybe the option should be removed to avoid confusion?

[MikaelFangel]

@hydrargyrum That's true. However I'm not in a position to make design choices regarding how a function should work. Maybe @maaslalani can be at help with this? And then depending on the outcome maybe I could propose a fix? 🥳