About column mode behavior

[noborus]

Table switch -c has no effect, file content is just displayed as usal (e.g. by calling "ov -c -d: /etc/passwd"). Using ov Version 0.4.0. Same effect with $HEAD. Distro is Mint 19.3.

Originally posted by @larsklemstein in #5 (comment)

[noborus]

I don't know yet.
It worked with me.

https://github.com/noborus/ov/blob/master/docs/image.md#column-mode-toggle-c
Does the highlight do not work on the left or right?

[larsklemstein]

The highlighting works on the left. Lars Am Di., 11. Aug. 2020 um 06:46 Uhr schrieb Noboru Saito < notifications@github.com>:

…

I don't know yet. It worked with me. https://github.com/noborus/ov/blob/master/docs/image.md#column-mode-toggle-c Does the highlight do not work on the left or right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMGOCGBUUWQY6U5OKDWAFALSADEJHANCNFSM4P2T5RMA> .

[ilius]

ls -l | ov --column-mode --column-rainbow just displays the output as normal less.
I don't think it's parsing tabular data correctly.

[noborus]

ls -l won't work because the delimiter will be multiple spaces.
#251 implementation is required to resolve.
For now, the only thing you can do is:

ls -l |tr -s ' ' '\t'|ov -d '\t' --column-mode --column-rainbow

[ilius]

I don't think that PR will resolve this.
Tabular data is not just about a delimiter.
The padding/alignment of columns (left, right or center) should be taken into account.
Because there may be columns (like dates, file names, etc) that have spaces.

Parsing tabular data accurately and correctly is not even always possible, since they may be ambiguity. But it's still worth to try our best, because there are so many Linux/Unix command line tools that produce it (and are not able to produce csv or json, sadly).

The README actually claims:

ov also has an effective function for tabular text.

which made me think it can actually parse tabular data.

[ilius]

A simple example of how tabular data can be ambiguous:

ov $ ls -l '--time-style=+%Y-%m-%d %H:%M:%S'
total 140
-rw-rw-r-- 1 s s  1110 2023-01-17 03:04:55 config_test.go
drwxrwxr-x 2 s s  4096 2023-01-17 03:04:55 docs
drwxrwxr-x 6 s s  4096 2023-01-17 03:04:55 examples
-rw-rw-r-- 1 s s  1766 2023-01-17 03:04:55 go.mod
-rw-rw-r-- 1 s s 54608 2023-01-17 03:04:55 go.sum
-rw-rw-r-- 1 s s  1069 2023-01-17 03:04:55 LICENSE
-rw-rw-r-- 1 s s 12842 2023-01-17 03:04:55 main.go
-rw-rw-r-- 1 s s   545 2023-01-17 03:04:55 Makefile
-rw-rw-r-- 1 s s   207 2023-01-17 03:04:55 ov-disable-default.yaml
drwxrwxr-x 2 s s  4096 2023-01-17 03:04:55 oviewer
-rw-rw-r-- 1 s s  3901 2023-01-17 03:04:55 ov-less.yaml
-rw-rw-r-- 1 s s  3658 2023-01-17 03:04:55 ov.yaml
-rw-rw-r-- 1 s s 22001 2023-01-17 03:04:55 README.md
drwxrwxr-x 2 s s  4096 2023-01-17 03:04:55 testdata

Are date and time in the same column or two different columns?

Or even worse:

ov $ ls -l
total 140
-rw-rw-r-- 1 s s  1110 Jan 17 03:04 config_test.go
drwxrwxr-x 2 s s  4096 Jan 17 03:04 docs
drwxrwxr-x 6 s s  4096 Jan 17 03:04 examples
-rw-rw-r-- 1 s s  1766 Jan 17 03:04 go.mod
-rw-rw-r-- 1 s s 54608 Jan 17 03:04 go.sum
-rw-rw-r-- 1 s s  1069 Jan 17 03:04 LICENSE
-rw-rw-r-- 1 s s 12842 Jan 17 03:04 main.go
-rw-rw-r-- 1 s s   545 Jan 17 03:04 Makefile
-rw-rw-r-- 1 s s   207 Jan 17 03:04 ov-disable-default.yaml
drwxrwxr-x 2 s s  4096 Jan 17 03:04 oviewer
-rw-rw-r-- 1 s s  3901 Jan 17 03:04 ov-less.yaml
-rw-rw-r-- 1 s s  3658 Jan 17 03:04 ov.yaml
-rw-rw-r-- 1 s s 22001 Jan 17 03:04 README.md
drwxrwxr-x 2 s s  4096 Jan 17 03:04 testdata

We don't know if date is one column or 3 columns by just looking at padding/alignment.

It may not matter much in some cases, but in some other unlucky cases, it can be important.

[noborus]

The README actually claims:

ov also has an effective function for tabular text.

which made me think it can actually parse tabular data.

I think it is unreasonable.
The output of ls -l is actually vertically aligned rather than tabular. So the README is not wrong.

Anyway, vertical alignment is difficult to parse.

[ilius]

I think in the context of command line (and not spreadsheets), vertical alignment is part of tabular output/data, because command line output is generally meant for viewing, searching or filtering (with grep/sed), not parsing.

Formats like csv and tsv are also tabular, but they are mostly spreadsheet-oriented I think.

Ideally all commands that print tables should be able to produce csv, tsv or json by giving a flag, but that's very far-fetching.

[noborus]

My reply remains unchanged, just repeating, but converted to discussions.

[noborus]

I made guesswidth to improve the display of width formats.
It can infer column widths in output with headers like ps (limited in ls).
I plan to introduce this to ov as well.

[visrosa]

The support for tabular data is one of my favorite features of ov.

I've been creating view modes for lots of specific stuff and amassing quite a wishlist of features. Relating to column mode, it would be cool to support tables when there's also the presence of non-tabular data.

It always bothered me how fstab is supposed to be a table but is always sloppily and confusingly formatted. Thank to ov and some preparation this is no longer an annoyance.

ov --column-mode --wrap=false --align -H1 --column-delimiter \t (bat -p --force-colorization -l fstab fstab | psub)

This required removing all comments from the file and some light text processing to turn repeating spaces into single tabs.

I assume it would be way too complex for little gain, but being able to ignore comments, or maybe being able to define specific ranges for tabulation, would be helpful in my current goal of pretty printing and paging all the things. Commonly there's files or command outputs that are ripe for formatting and would require little or no preprocessing, if not for some small thing such as notifications messages sent along to STDIN , or comment strings.