This is heavily influenced by personal taste, but I don't understand the value of having so many elements of the output colorized. File type seems a useful case, everything else in the output of `exa -l` just looks distracting to me. Just my 2 cents.
The more design elements you add - colors, type, graphics etc - the more distracting the design get and the more conflict there is between the design elements. By colorizing everything here, nothing is important anymore. It's just poor usability and design.
You know what's funny? Every time I have to use ls, I'm so used to seeing the colours that I have so much trouble finding anything. Which column in the permissions is group-read? I can just scan for the green one. Which file in the listing am I supposed to be looking at? I just look for the one with the yellow underline. Colours have familiarity to me in a way that letters and words do not -- if I expect to see green and instead see grey, I'll notice it faster than if I expected to see "r" and instead see "-".
Of course, not everyone feels this way. Colour terminals are not a new invention, and if the "colour in everything" crowd was larger, someone would have made exa sooner.
That said, I don't want to go too overboard with the colours. Here's an example: when exa was in its infancy I had the bright idea to highlight the root user in red, in the same way that it highlights your current user in yellow, because, I don't know, root is "dangerous" or something. I ended up seeing so many red usernames that I stopped seeing it as "dangerous, beware" and started seeing it as "just another file" -- which completely defeated the point! Now, red is a lot more scarce (just +w permission and inodes. probably some file types. not many)
> Colours have familiarity to me in a way that letters and words do not -- if I expect to see green and instead see grey, I'll notice it faster than if I expected to see "r" and instead see "-".
I think the coloration is good, but I would have defaulted a bit differently in the permissions. I would have made all user bits green, all group bits orange, and all other bits red. Not only does this denote the possible security implications of the permissions, but it also maps well to what I'm usually looking for - what are my permissions, and being able to see all those quickly with green would be useful. As an added benefit, there wouldn't be as many per-character color changes in that section, so it would be less busy.
Awesome work, BTW. I love seeing interesting re-imaginings of old standby utils. I was actually thinking of doing my first real Rust project as a cat replacement. I was thinking of calling it calico. ;)
I really like a lot of the extra colors but I was also overwhelmed by the rainbow permissions. User, group, world are the organizing principle for me. World writeable is something I never want to have in my mind as similar to user writeable.
I like the colors, but I'd like to be able to configure what's colored and, more importantly, what gets bolded. For me, the bold stuff jumps out and can kind of push the non-bold stuff into the background, which makes scanning that stuff a bit harder. (In case you're wondering, I think I'd skip bolding the username and the owner perms.) Also, I think that setuid bits are probably worth bolding, because you probably shouldn't see them very often.
Thanks! Configurable colours are something I'd like to get done, too. About half the work has been done to achieve this -- none of the colours are hard-coded, they're all looked up from a big Colours value that gets passed around internally. This value just needs an interface so it's configurable by the user. I've been meaning to open it up to the community instead of just defining an ad-hoc EXA_COLO[U]RS environment variable, but y'know, time.
I'd settle for a flag that disables the rainbow perms, it seems to be a common gripe. It's nearly a dealbreaker for me. But, that's personal preference - congrats on a great util.
For me it is always difficult to see the groups in the permission groups, I would prefer the user part would have one color, the group part another... identifying if there is a r or w is not the problem. There should maybe be also between the groups a space, just to make the output more readable. Otherwise I would like to not see the file creation/change date at all, since most times it adds no valuable information. To get more verbose output - with date info, there could be something like exa -ll (make the output more verbose if there are more -l args present).
I'm a big fan of this colorization. I like that I can quickly scan permissions, take note of the user, and figure out what kind of file I'm looking at. With regular 'ls', I usually have to do a double-take on all of those.
I heavily rely on colorization to read what I need to on the terminal. I pipe almost all of my logs through ccze by default. Thanks for this great tool -- installing.
I agree with your main thesis that colour adds information.
But not with your reaction to colourblindness - it's surprisingly common. We changed a grid of clickable red/green squares to add crosses and ticks after a chance comment, and several more users bothered to contact us about how much easier it made the UI.
So please DO give a... fig... about colourblindness - if it's worth adding colour to help users, surely it's also worth a little thought about how to cater for colourblind people. In this case, a grey-scale palette perhaps?
ow my eye sockets hurt! I always love when I get punished for something of a genetic and physical nature that I had absolutely no control over whatsoever!
but in all fairness, other than what you had to say about colorblind people, I more or less agree with your other words and claims. but seriously: i didn't choose to be colorblind and I honestly do hate it sometimes.
I am mildly colorblind but fortunately this does not impact my life too much. There are exceptions though :
- when I was maybe 12 the ophtalmologist told my father in from of me that I should forget about engineering and science in general. Take it dumbass, I am an engineer and PhD in physics (I had to let this out one day :))
- I was shopping for school supplies this morning and had to ask someone to help me choose the copy books so that they are of various colors and not pink. She was surprised at first but then we ended up with a nice talk.
- I reflashed a router 5 times as the flashing was failing, the LED was red. My brother was walking by and told me it is actually green, ending my agony. The router survived.
- a support guy flew cross country once to support my switches which were failing. As you can imagine they were not, I thought that the LEDs were red but they were green (maybe the ophthalmologist was right after all. Still a dumbass for saying this in front of a pre-teen geek who could have listened and go for liberal arts)
- my boss (a lady) told me that I wear interesting color combinations. I thought I was always wearing a combinaison of beige and pale blue. I was not.
I haven't used it yet, but the colored screenshots look way more usable than standard ls. Personally I don't think it id conflicting and confusing at all.
The screenshots also show that the color palette is designed solely for black-background terminals. It will be useless on white or grey, perhaps passable on blue.
Tell me. I am curious to know if use a text editor without syntax highlighting.
Seems to be the case that there is no modern text editor that doesn't color every single word. Must be so hard for you now that you're forced to use these tools with such "poor usability and design". How do you even manage?
That's partly the reason why I tend to avoid software with "modern" in its description... but more seriously, I don't care much for syntax highlighting --- I can put up with it (unless the colours are too distracting), but I do prefer monochrome text.
grep does have `--color=auto`, though, which checks whether you're printing to a terminal or not.
exa's opinion is this: users shouldn't be expected to know that adding colour to ANSI terminal output adds more bytes to the stream. If you run `foo`, see that it outputs a line, then run `foo | grep line`, you'd expect to see that line without having to stop and think about what representation the colours had.
Yeah, it's annoying that less is one of the few programs that doesn't alter its input and would be a perfect use case for reading in ANSI codes. There's just no way for exa to know that it's being piped into less while keeping the above rule true too.
> it's annoying that less is one of the few programs that doesn't alter its input and would be a perfect use case for reading in ANSI codes.
I'm not certain if it's exactly what you're getting at, but less can be instructed to parse ANSI color sequences, and output them, with the -R flag. (If you forget to put -R on the command line, or some utility automatically starts less for you, you can also type "-R" while in less to trigger that behavior.) That said, less has to be fed the sequences, and most programs will not output color sequences when piped to less, as they detect that the output isn't a TTY (this is normally the right thing to do, it just kinda sucks in less's case) so you might need to, e.g., that_prog --color=always | less.
> There's just no way for exa to know that it's being piped into less while keeping the above rule true too.
Yeah, this is the real problem. I kind of wish there was some sort of content negotiation between piped utilities, s.t. less could inform the upstream utility of "hey! I speak ANSI color codes!".
What follows is definitely well into the "WTF too clever" column and I do not recommend it, but, this is HN: I presume you could riff through /proc trying to find the other end of the pipe that you're writing to (I think /proc on Linux has that) and then, if the executable's name is "less", well, you see where I'm going…
That's where you need something like PowerShell, which pipes objects around instead of streams of bytes which are probably text.
Of course, PowerShell has its own issues, but the idea of a shell with more meaning attached to things is appealing. Rebuilding an ecosystem that can handle it all though... not so plausible!
I don't know if exa does this, but most command line tools disable colorized output automatically if they determine that stdout is not an interactive terminal.
