Ability to configure custom column separator

[UrsaDK]

Depending on your configuration (ie: blocks shown and date format) output of ls -l can become quite dense. Columns are separated by a single space, yet column values can also include spaces… This, on occasion, makes it challenging to see where one column ends and another one starts.

It would be awesome if we could configure a custom column separator.

How I imagine it to work

Column width would be calculated as it is now but the columns would be joined using a custom defined string. This string would default to a single white space ( ), but could be re-defined in the configuration file (eg: columns-separator) and, possibly, via a command line switch.

Since the default value for the separator would be a single white space ( ), the default behaviour of lsd would remain consistent and compatible with GNU ls.

Those who want to space their columns a bit more generously could change the separator to a double space (eg: ) or event to something really fancy, like ⋮.

[meain]

How do you expect this to work when we have something like this?

$ ls -l src --blocks name,size
app.rs          15K
color          4.0K
color.rs        13K
config_file.rs  12K
core.rs        5.5K
display.rs      25K
flags          4.0K
flags.rs       5.0K
icon.rs         28K
main.rs        3.3K
meta           4.0K
sort.rs         12K

[UrsaDK]

That's a very good point! Luckily, I don't think the configuration of --blocks (supplied either via the config or on the command line) would affect this feature. Let me explain what I mean by that:

First and foremost, I think custom column separator could be implemented in such a way that it maintains backwards compatibility for all of the existing users, ie: if a user is using a default separator then they should see no difference in the output of lsd after the release of this feature.

Looking at the above output, we can see that it consists of two columns: "name" (red) and "size" (blue). The columns are sized to accommodate the longest displayed item, and are separated by a single white space character, which I propose should be the default separator.

As long as the user doesn't modify the default separator then the output of the program will be unaffected by the introduction of this feature. This would hold true irrespective of the user's --blocks configuration, as currently all columns, irrespective of the order in which they are displayed, are separated by a single white space character.

However if the user sets a custom separator, for example a double space ⎵⎵ or "a line of dots" ⎵...⎵ (I'm using ⎵ to represent a space so that markdown doesn't swallow those characters), then the columns would be joined using that custom separator instead of the default one.

In the case of the examples I used above, the output would look something like this:

1. Column separator is set to double space ⎵⎵:

2. Column separator is set to "a line of dots" ⎵...⎵:

Please note that the only reason I picked ⎵...⎵ string for the second example is because I am using Photoshop to generate the examples from a screen grab of the output you provided above. Short of using letters or numbers, a dot is the only reasonably useful column separate character available in the original output.

In reality, if this feature is implemented, a user could define any combination of characters as their custom column separator.

Obviously, not every string would make sense as a column separator, and some strings ideally suited for a given configuration of --blocks would be nonsensical if that --blocks configuration was to change. However, I am going on the assumption here that if a user had the technical knowledge to set up a custom column separator then they would be savvy enough to recognise and adjust its value if and when required.

[alexandertrefz]

That is precisely how I would want this feature to work, and exactly why I arrived at this issue :) I think this would be a very clean way of implementing this, it would also allow for more visually advanced options, like | as a separator, giving a more table like appearance, etc.

[alexandertrefz]

It seems to me that the term_Grid already supports this behaviour, and all that needs to be changed is that this line gets exposed to the mentioned flag, as per their docs.