Add code for file types (image, document, etc.) in EXA_COLORS

[ariasuni]

• Added mh in LS_COLORS, seems like it was forgotten
• Add ten new codes in EXA_COLORS for file types

Fix #363

In the future, we should probably use some kind of config file for theme, because EXA_COLORS tends to be long and cryptic.

[ogham]

In the future, we should probably use some kind of config file for theme, because EXA_COLORS tends to be long and cryptic.

Yeah, I agree: there's way too much functionality stuffed into that environment variable. The reason exa highlights lots of file types by default is because I didn't want to muck around with defining a long complicated configuration string when instead I could just write code.

Something I'm worried about is the categories of file type becoming "ossified" before thought has been put into which categories there should be. Right now there's temp files, immediate files, images, videos, music, lossless music, cryptographic stuff, "documents", archives, and build artefacts. But the only reason there are these ten categories is because those were the sort of files I was regularly dealing with in 2014. Seven years later, I don't keep lossless music anymore, I don't have to work with cryptographic files, and I see a lot more text files ending in .md or .adoc that there's not even a category for! My worry is that by exposing the categories to the user as colours that can be configured together, exa will define what its categories are before it is ready. Please tell me if you don't see what I'm saying here.

A couple other things about this:

1. ls's mh code actually does something different from exa's lm code: ls highlights the file name in all views, but exa just highlights the number in the link column. exa should probably grow support for the former at some point, but that's the reason it was omitted from the list. (Granted, there were no tests defining this exact behaviour.)
2. I quite like the term "build files" instead of "immediate files". At the start, I needed a term that encompassed both build configs and READMEs, and "immediate files" was the only term I could think of, but history has shown that term to be vague and not understandable by people. You rarely see READMEs outside of code projects, so "build files" might be close enough.
3. Similarly, "file kind" is a much better term than "file type" when we're talking about files/directories/links/sockets instead of documents/pictures/music.
4. I kind of feel like if there's a way to colour all files of a category, people will expect there to be a way to add a file to a category, too; instead of telling exa to "highlight .md files in colour #105", people will want to "highlight .md files as documents", where documents are that colour. This would involve putting even more functionality in the environment variable. Or am I getting ahead of myself here?

[ariasuni]

Something I'm worried about is the categories of file type becoming "ossified" before thought has been put into which categories there should be. Right now there's temp files, immediate files, images, videos, music, lossless music, cryptographic stuff, "documents", archives, and build artefacts. But the only reason there are these ten categories is because those were the sort of files I was regularly dealing with in 2014. Seven years later, I don't keep lossless music anymore, I don't have to work with cryptographic files, and I see a lot more text files ending in .md or .adoc that there's not even a category for! My worry is that by exposing the categories to the user as colours that can be configured together, exa will define what its categories are before it is ready. Please tell me if you don't see what I'm saying here.

Well, maybe it’s time to rethink those categories then.

Categories I feel are useful:

• documents, images, videos, music and archives are clear cut categories that everyone uses.
• I believe that a lot of exa users are building software, so immediate/build files are also a must-have I believe.

Categories I feel are not that useful:

• I like the idea of being able to differentiate music and lossless music with a slightly different color but maybe it’s not that useful for such a limited category of files.
• I’m not sure about temp files. Are there this frequent?
• Cryptographic files tend to appear in very specific directories so it’s not that useful to color them specifically I suppose.
• Build artefacts tend to appear in very specific directories too, even hidden in most modern workflows, so same as above. I also don’t really like that I needs to look in the parent directory for corresponding source files, even if it’s not slowing exa enough to be perceived by the user.

Categories I feel could be added:

• A category could be added for executable files.
• A category could be added for plain text documents (.md, .rst, .adoc, README — by removing it from “immediate files” — LICENSE/LICENCE, NEWS, CHANGELOG, etc.)
• A category could be added for config/data files (.json, .yaml, .toml, etc.)

ls's mh code actually does something different from exa's lm code: ls highlights the file name in all views, but exa just highlights the number in the link column. exa should probably grow support for the former at some point, but that's the reason it was omitted from the list. (Granted, there were no tests defining this exact behaviour.)

So, do you think exa should ignore mh from LS_COLORS for now?

I quite like the term "build files" instead of "immediate files". At the start, I needed a term that encompassed both build configs and READMEs, and "immediate files" was the only term I could think of, but history has shown that term to be vague and not understandable by people. You rarely see READMEs outside of code projects, so "build files" might be close enough.

Yeah, I think immediate is confusing and found that it may make sense to include README since they very often include build instructions. README could also be reclassified in a new category as proposed above.

Similarly, "file kind" is a much better term than "file type" when we're talking about files/directories/links/sockets instead of documents/pictures/music.

Yep, I believe it makes sense to think of exa’s colouring as first taking “type” into account, i.e. the different types of files for the filesystem (based on filesystem type), and then, if they are normal files, what kind of normal files they are (based on name).

I kind of feel like if there's a way to colour all files of a category, people will expect there to be a way to add a file to a category, too; instead of telling exa to "highlight .md files in colour #105", people will want to "highlight .md files as documents", where documents are that colour. This would involve putting even more functionality in the environment variable. Or am I getting ahead of myself here?

I don’t know. I think ideally, I would want a config file where you can define colors for categories, and easily put a bunch of globs (maybe something very simple like taking into account only stars at the beginning of the pattern, at the end, or both) and assign them a color, and then it won’t be necessary to worry about a long environment variable.

In the meantime, I wanted to be able to define 100% of exa’s colours without needing to compile my own version with a patch.

[Tuurlijk]

Seems to me that .dircolors is the way forward. Most people have it in in place and it it flexible and battle tested format. We can all categorize our own files there. Once I have gotten through the rust exercises on exercism . . . I may write a patch to fetch color data from the already existing LS_COLORS env var. We still need a place to specify the colors of the other fields, so keeping EXA_COLORS is fine. Maybe one should override the other.

[ariasuni]

We already take colors from LS_COLORS, and EXA_COLORS overrides it, and also has more codes (which is why dircolors won’t work exactly for exa I believe…). So there’s no obvious solution in my opinion

[roland-5]

Sorry if this is a noob question: exa uses LS_COLORS which is part of coreutils and is written in C and has its own EXA_COLORS implementation which overrides LS_COLORS. If I understand correctly, this project - lscolors - is an implementation of LS_COLORS (from coreutils) in rust. Wouldn't it be easier for exa to drop the current solution (LS_COLORS + EXA_COLORS) in favor of lscolors?

[eggbean]

@roland-rollo: LS_COLORS and EXA_COLORS are variables. echo $LS_COLORS to see it if it exists. You can customise LS_COLORS using the dircolors command (and a dir_colors file). Read up man dircolors.

[eggbean]

@roland-rollo Oops, sorry, I meant read up man dir_colors which says a lot more about it all.

[roland-5]

@eggbean Thanks! I read it all and now better understand what's going on. Is it any helpful that there is coreutils written in Rust and so dircolors? I started learning Rust, so at this moment I still can't help, but if I understand correctly, there isn't now any elegant way to deal with modification of colors for things that are hardcoded?

[eggbean]

@roland-rollo I don't know what you mean. There are default colours for LS_COLORS and EXA_COLORS and they can be overridden as far as I know. It's been a while since I defined mine and I haven't touched them in years, so maybe someone else can help.