fix node style with no LS_COLORS set

[Locorock]

Fixing the issue mentioned #651 Instead of calling for default() on LsColors it calls on empty() in order to avoid injecting a default style Tested with and without LS_COLORS set and it seems to do the trick

[Locorock]

Actually hold up, i'm still getting some issues with the default config, i'm going to need to test this one a bit more

[Locorock]

I'm giving priority to config defined styles and falling back to ls_colors if they are not defined for an element, not sure if that is the intended behavior, i'm going to need some input here

[sayanarijit]

Sorry, I haven't been able to review this. I'll do it soon.

For now take a look at these for the intended behaviour:

• https://github.com/sayanarijit/xplr/issues/640
• https://github.com/sayanarijit/xplr/issues/620

[Locorock]

So, from what i understand the priority should be like this: Specific Node Style (mimetype, extension, special) > LS_COLORS > Generic Node Style (file, table, tree, etc...)

Instead of right now: LS_COLORS > Specific Node Style > Generic Node Style

But the lua implementation only allows the current implementation OR the opposite: Specific Node Style > Generic Node Style > LS_COLORS Because we get meta_style which is the style from config (specific and generic already mixed) and ls_style which is from LS_COLORS

[sayanarijit]

Damn, it's getting complex :sweat_smile: ... I need some more time to remember and document things (as I'm sure I'll forget it again).

But as of now, IMO, the priority should be:

xplr.config.node_types (it's empty by default) > $LS_COLORS.

If $LS_COLORS is unset i.e. LS_COLORS= xplr, xplr will copy the behavior of ls, i.e. default to a stock $LS_COLORS.

xplr.config.node_types prioritizes specific over generic, and the final value can be obtained dynamically by xplr.util.node_type.

i.e. specific xplr.config.node_types > generic xplr.config.node_types > $LS_COLORS

So, $LS_COLORS is the most generic, because it applies across different tools.

Note that this isn't the case for ~master~ main branch. The dev branch should have the correct behavior though, but I need to check again.

[sayanarijit]

But I guess it makes sense to be able to ignore $LS_COLORS completely. Maybe ls is wrong, and we can treat empty as actually empty, rather than default.

Another option is to treat unset and "" differently, but that'll probably add more confusion.

Another option is to add xplr.config.general.disable_ls_colors, which would be ideal, but feels a bit of overkill.

[sayanarijit]

Closing this as the intended behaviour is to prioritize init.lua over LS_COLORS.