Lsd: Themes

[erusev]

It seems like the colors that lsd uses are hard coded. It'd be awesome if it supported custom colors.

I'd love to develop a theme that uses colors for file names and shades of gray for everything else - lighter shade for more recent dates and larger file sizes.

[Peltoche]

Hi @erusev ,

There is currently a PR about an integration with the LS_COLOR variable (#84), it should allow to customize some of the colors. If you need a deeper color integration, for the sized for example, I think it would be possible to create a theme, the colors.rs module can be easily customized for it. The only thing is that for now the themes are hardcoded and if everyone add his own, it will be a real mess.

A possible solution would be to create a new flags allowing to load a file describing the color theme. Something like:

lsd --theme-file=~/.my-custom-theme.json

and inside ~/.my-custom-theme.json:

{
 "file": 230, // Cornsilk1
 "dir": 33, // DodgerBlue1
 ...
}

What do you think of it?

[erusev]

Yes, making it possible to load the theme from a separate file would be ideal - it could be a flag that sets it or a config variable as in https://github.com/sindresorhus/pure (under the options section).

[kmoschcau]

Hi, I am interested in working on this when I find the time, I have some questions though:
Do we want to use JSON or should we maybe use something more human friendly like YAML?
And if we add a config file like that, should we make it possible to put more than just the theme in there?
And finally, if we add config files, I would like to support the XDG Base Directory Specification. What do you guys think?

[Peltoche]

Hi @kmoschcau , thanks for the proposition!

Do we want to use JSON or should we maybe use something more human friendly like YAML?

Personally I prefer json but I guess that YAML is more adequate for human redable configurations. If it's possible to handle the two it would be perfect but it's not a priority.

And if we add a config file like that, should we make it possible to put more than just the theme in there?

Absolutely! The goal would be to accept any flags as a configuration.

And finally, if we add config files, I would like to support the XDG Base Directory Specification. What do you guys think?

I guess it would be a good idea. In any cases, it would be great if we can override the default (or XDG) path by one specified as an argument.

Don't hesitate, if you have more questions or if you need reviews

[kmoschcau]

I am not sure about arguments to set the paths, but the specification lists some environment variables to set those paths. But the rest sounds good to me, I hope I can find the free time to work on this soon.

[kmoschcau]

One thing I just found out about recently: YAML is actually a superset of JSON, so any valid JSON is also valid YAML. So a good YAML parser should support both.

[vks]

What about TOML? It serves a similar purpose as YAML, and it is quite a bit simpler.

[kmoschcau]

That depends a bit on what kind of config values one wants to store. TOML could actually be better for this case (because simple), but I have not really seen it outside of the Rust ecosystem yet. Might confuse some users, but also might not because it is so simple.

[kmoschcau]

I just had a look at the TOML specification and to be honest, if it gets to more complicated stuff I find YAML to be easier to comprehend as a user. I will have a look at a first implementation with YAML.

[kakulukia]

This is my config for colorls and while the multiple colors for different file types is cool, 10 different colors is a lil much. Im all in for themes!

[kmoschcau]

@Peltoche I have a question concerning code organization. Since the Flags::from_matches function is already fairly large, I started to implement constructor functions for every single flag enum directly. I also wanted to add test methods for those constructor functions. However this will really blow up the size of the flags.rs file. So I would suggest moving those flag enums into their own respective files and put all of that into its own module dir. Since this is a pretty substantial change, I wanted to have your opinion on it first.

[Peltoche]

Hi @kmoschcau, I think this split would make total sens. Moving the flag parsing next to the meta options would make it easier to read as we can see all the flag lifecycle in one place.

[kmoschcau]

Some things also came to mind: We probably need some additional flags or just simply --no-... versions of flags to disable behavior that is enabled by the config.

Also I think the --oneline flag name is misleading. It should be something along the lines of --one-per-line or something like that.

And another thing I came across that is really confusing: Why is the --group-dirs option (and some others as well) set up to be able to be specified multiple times, but it only ever uses the last value given?

[kmoschcau]

Just to give an update. I am so far done with implementing on my side, I just have some catching up to do with master. I hope I don't miss anything. :D

[swedneck]

any updates on this? lsd looks lovely but not using $LS_COLORS is a rather big turnoff for me

[kmoschcau]

I am still waiting on my configuration file merge request to be merged. Once that happens, I would start with adding theme configuration things.

[kakulukia]

@Peltoche - please merge :)

[zwpaper]

hi @kmoschcau , may I ask how is the progress of theme configuration?

maybe we can split the work and make it happen faster together

[zwpaper]

as this is requested from time to time, I am trying to start my work for lsd theme, If anyone has started, please let me know!

[kmoschcau]

This should certainly be easier now, since you can now save if in the config file. I'm not sure whether it would be beneficial to be able to specify an entire theme via CLI options.

[zwpaper]

Hi @kmoschcau , thanks for the work on the config file.

I don't think to specify an entire theme via CLI options would be a great idea, this would make the options too complicated.

I will implement one option(and one in the config file) to specify the path of the theme, as a standalone theme file would be easier to switch between themes.

[kmoschcau]

There is some merit to putting themes into their own files. But have you also considered putting them in the config file with the key being their name?

[zwpaper]

putting themes in a single config file make it simpler, that is good!

but I preferred standalone file because:

1. changing themes always replaces the whole theme, and not much chance changes some color inside it.
2. standalone file makes it easier for sharing

the theme name as the key may also be a good choice, but in my personal experience, I don't like the dynamic yaml key much...

[kmoschcau]

Well there wouldn't really be much dynamic about. The way I would make it is to have a root level key themes, which has an array of theme name keys, which then hold the color specifications.

But yes you could also just replace that mechanic by pulling out the color specifications into their own files. If you do that, it is worth thinking about putting those into their own subdir.