Repository: saulpw/visidata

Issue:
fixed width saver truncates data if columns are not fully expanded
**Small description**

If you save or syscopy a table as `fixed` format, and the visible column width is less than the width of the data in the column, the data is truncated. Also, the resulting file is not a valid fixed width format file as the columns are not aligned with the headers.

**Expected result**

Saving or copying a table when the columns are not fully expanded should yield the same result as when the columns are expanded.

**Actual result with screenshot**
![image](https://user-images.githubusercontent.com/2499066/231616002-553a1a46-0b56-4950-b3eb-90507a77b823.png)

**Steps to reproduce with sample data and a .vd**
[test-vd-fixed.zip](https://github.com/saulpw/visidata/files/11217144/test-vd-fixed.zip)

**Additional context**
saul.pw/VisiData v2.11



Discussion:
Hmm... Looking at the code, it looks like the truncation behaviour is intentional?
https://github.com/saulpw/visidata/blob/d40fc931fc63c72a7d94a00b1a818bb4ac24b13e/visidata/loaders/fixed_width.py#L87

I wouldn't normally expect a display mode to change the underlying data.

Also, I suspect there's something funny going on here, which is leaving us with a missing space in the truncated version:
https://github.com/saulpw/visidata/blob/d40fc931fc63c72a7d94a00b1a818bb4ac24b13e/visidata/loaders/fixed_width.py#L95
Yes, this behavior is (somewhat) intentional; the widths of the columns indicate the fixed widths of the fields.  This is so you can set them precisely, in case the fixed file format has an exact specification.  I agree though that it's undesirable to have the data truncated otherwise.  What's the better thing to do here?  Find the max width and use it instead of the column width, if it's larger?  and warn or ask for confirmation if this is the case?
@daviewales, do you have a preference wrt:

> What's the better thing to do here? Find the max width and use it instead of the column width, if it's larger? and warn or ask for confirmation if this is the case?
My preference would be to always use the true max width by default, so data is never truncated. Truncation could be a separate feature which you explicitly opt into. (Save view vs save data?)

Admittedly, my use case for this is non-standard.
I use the fixed width saver to paste tables into emails and into MS Teams within code blocks. (`gY fixed`)
They look beautiful, but it's a surprise when the data is truncated.
Okay, I pushed that change to `develop` @daviewales! Try it out, and let me know how it feels. =)

Resolving patch:
diff --git a/visidata/loaders/fixed_width.py b/visidata/loaders/fixed_width.py
--- a/visidata/loaders/fixed_width.py
+++ b/visidata/loaders/fixed_width.py
@@ -84,8 +84,7 @@ def save_fixed(vd, p, *vsheets):
             widths = {}  # Column -> width:int
             # headers
             for col in Progress(sheet.visibleCols, gerund='sizing'):
-                maxWidth = col.getMaxWidth(sheet.rows)
-                widths[col] = col.width if col.width >= maxWidth else sheet.options.default_width or maxWidth
+                widths[col] = col.getMaxWidth(sheet.rows)  #1849 
                 fp.write(('{0:%s} ' % widths[col]).format(col.name))
             fp.write('\n')
 


Test patch: