Is --smart-group working as expected?

[StayPirate]

I noticed that --smart-group only works if --group is also enabled used (which is not by default) and I find this weird.

I propose the two following alternatives:

1. If the user enable --smart-group he'll be advised that he also has to add --group
2. --smart-group implies --group enabled even if it's not specified

I prefer the second solution because IMHO if an user enables --smart-group he expects the flag to work, regardless if --group is enabled or not.

[cafkafk]

I think second makes more sense as well tbh, although this approach doesn't allow people to define smart-group in their alias but enabling group at their discretion.

[StayPirate]

are you talking about people who occasionally show groups by running eza -lg? I personally set -g in my ll alias, but I understand that that could be a real-case scenario for some users.

[sebastiancarlos]

My two cents: I initially supported the idea of making --smart-group imply --group, but on second thought I think the current behavior is better, as it allows more flexibility.

As @cafkafk said, the current behavior allows what I call "The Most Interesting Man In The World Meme Options Pattern", aka "I don't always use --group, but when I do, I have --smart-group in my alias."

I think this is a reasonable behavior and similar to the trade-off between verbosity and flexibility taken by many nix*/GNU tools.

[StayPirate]

I agree with both of you, this way allows more flexibility. Nevertheless, I would add a line to the man page to inform users that --smart-group only works if the --group flag is enabled.

[liketurbo]

I can suggest making the --group option accept the values regular (default) or smart and getting rid of --smart-group

[StayPirate]

That sounds like the best solution. +1

[StayPirate]

any plan to implement it for the next release?

[liketurbo]

The thing is that --smart-group has already been released, and getting rid of it would be a breaking change ... @cafkafk, can that option be removed since it's only in the latest release?

[sebastiancarlos]

I would also like to point out that making --group an option that takes an argument could also be a breaking change. But that would depend on how the command line argument parsing is implemented, which I do not know.

[tribut]

This would also solve another problem not yet mentioned:

Currently its not possible to have smart-group be the default and show full group output on demand:

alias eza='eza --group --smart-group [more defaults]' # No way to disable --smart-group later

[nestor-custodio]

FWIW, the --smart-group option sounded great when I read about it in the help text, but it took some sleuthing to figure out that --smart-group on its own does nothing. I'm on board with --smart-group implying --group, as was suggested above. As for the "it's more flexible as it is now" argument, I think there has to be a misunderstanding.

The way it works now (a) is:

• if you always want to see the group, you use --group
• if you want to selectively see the group, you use --group --smart-group

The way it would work as proposed (b) is:

• if you always want to see the group, you use --group
• if you want to selectively see the group, you use --group --smart-group or the less verbose --smart-group

I don't see how (a) is more flexible than (b). If anything, it's the opposite, as (b) gives you an additional way of asking for what you want?

It's also been expressed that "if my alias has --smart-group in it, but not --group, then I can get the --group --smart-group benefit by just saying --group and that's less verbose, which is convenient", which is entirely correct, but if anything that's an admission that having to say --group --smart-group is too verbose and "wouldn't it be nice to have a shorter way to say that?" which is exactly what the "--smart-group implies --group" proposal would do. This benefit would of course be on top of the flags behaving in the way that seems more natural just based on their names.

#my¢2

[sebastiancarlos]

I don't see how (a) is more flexible than (b).

Two additional cents: The "it's more flexible as it is now" argument, as it was expressed so far, is not really about that (a)/(b) comparison, but rather abut the fact that "if my alias has --smart-group in it, but not --group, then I can get the --group --smart-group benefit by just saying --group and that's less verbose, which is convenient."

Of course, whether that is "flexibility" or "a workaround to a problem of too much verbosity" is up for debate.

To phrase the dilemma in other words, the "flexibility argument" assumes that many users like the --smart-group feature, and yet they might not always want to see group information:

If that assumption is correct, then the user would endure more typing in the "--smart-group implies --group" proposal on those occasions when they want to see group information:

I would also add that, whatever is decided, the documentation should be more clear to reduce sleuthing time.

[injust]

Ouch, I just ran into this. Spent the longest while wondering why --smart-group wasn't working.

IMO this is a bad default (and not being documented makes it even more painful).

--smart-group and --group should be consistent with how --git-repos-no-status and --git-repos work, i.e. without having to specify both.