from-ssv cuts off columns from lsmod

[sophiajt]

Describe the bug
If you do lsmod | from-ssv, the results seem to cut the columns evenly without separating based on spaces. Example in screenshot.

To Reproduce
Steps to reproduce the behavior:

1. lsmod | from-ssv

Expected behavior
Even if columns don't perfectly line up, I think we want to "do the right thing" and just parse them based on the spaces rather than guessing the columns. We could retain the column mode as a separate flag.

Screenshots

Configuration (please complete the following information):

• OS: Linux
• Version: 0.4.1
• Optional features (if any)

[sophiajt]

cc @t-hart

[sophiajt]

Just as one more data point: lsmod | from-ssv does seem to work in 0.4.0, so it may have been from the updated logic between 0.4.0 and now.

[thomasheartman]

Ah, that's a great use case for it! Good one. It seems that the readme hasn't been updated, by the way (and I also notice that the format for flags for the from-ssv command is inconsistent with the other commands (date, post, exit, for instance). I don't know if that should be kept up to date continuously or updated once something has been properly settled.

Also, how should the command handle missing columns/values? The current version will collapse multiple separators if there are any, which means that you may get rows with different numbers of columns. Both from tsv and csv error in this event, telling the user the input can't be parsed, but I'm not sure the command should be that strict. Or if it should, maybe it should give the user a clearer error indicating that the parsing result has an uneven number of columns and that maybe they want to try --aligned-columns instead.

[sophiajt]

Good question - this feels like something we'll need a few examples from the real world to play with and try to understand how people who are using the command will need it to work. Did you have a few examples lying around that you want to work? We could scrub them and use them in our tests/designs.

[thomasheartman]

Sure do! A very stripped down version of the issue is the file:

one  two  three                                                                                                                   
a    b    c                                                                                                                       
1         3                                                                                                                       

When parsed without the --aligned-columns flag, you get this:

━━━┯━━━━━┯━━━━━┯━━━━━━━
 # │ one │ two │ three 
───┼─────┼─────┼───────
 0 │ a   │ b   │ c 
 1 │ 1   │ 3   │  
━━━┷━━━━━┷━━━━━┷━━━━━━━

With --aligned-columns, you get this:

━━━┯━━━━━┯━━━━━┯━━━━━━━
 # │ one │ two │ three 
───┼─────┼─────┼───────
 0 │ a   │ b   │ c 
 1 │ 1   │     │ 3 
━━━┷━━━━━┷━━━━━┷━━━━━━━

In this example, the table is clearly designed to be used with aligned columns, and so that naturally gives a better output, but what if the file looked like this?

one  two  three
a  b  c
1    3

In this case, the columns aren't aligned and the space separator is used as a hard limit. Is this intended to be turned into this?

━━━┯━━━━━┯━━━━━┯━━━━━━━
 # │ one │ two │ three 
───┼─────┼─────┼───────
 0 │ a   │ b   │ c 
 1 │ 1   │     │ 3 
━━━┷━━━━━┷━━━━━┷━━━━━━━

At the moment it won't because extra spaces after the separator before a different character get collapsed into the separator.

And the same goes for something like this:

one  two  three
a  b  c
1  2

where the last row only has two values where the other rows have three. Is this well formed?

There's quite a few ways of coming at this, and I'm not sure what the best way to solve it is. We could say that missing values are allowed, but only with --aligned-columns, unless we can find some clever way to deal with it for unaligned columns too. With lsmod, for instance, you can't not collapse the extra spaces because you'd end up with a number of empty columns that don't map to anything.

Anyway, I really appreciate your feedback and perspectives. Seeing as there seems to be a fair bit more to discuss on this, should we open a new issue for it?