[general_pizza]

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.

[arkitaip]

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.

[cytzol]

(author here)

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)

[kbenson]

> 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. ;)

[dfc]

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.

[SrslyJosh]

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.

[cytzol]

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.

[turnspike]

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.

[cytzol]

Cheers. Yeah, most of the comments on the colours have mentioned the permissions column in particular!

[sylvinus]

I feel your way too. Colours can add valuable information when done right.

Don't feel too let down by the comments on HN. Awesome work!

[thibran]

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).

Just some ideas, maybe you like some of them :)

[antjanus]

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.

[bowmessage]

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.

[yoodenvranx]

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.

[dingaling]

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.

[LASR]

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?

[userbinator]

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.

Related: http://www.linusakesson.net/programming/syntaxhighlighting/

[thomasz]

Did he seriously just throw random colors on random words and compare that to syntax highlighting?

[spike021]

I like color formatted text if possible, but more so just for keeping columns in a tabular output more easy to tell apart.

Just clicked-through to see what you meant about `exa -l` and I agree. When individual characters have different colors that's just way too much.

[weavie]

I sometimes use lolcat, just because I like colour. I just find it helps cheer up a little bit. I guess it is just personal preference..

[ShabbosGoy]

I also don't like colorized output - for instance, what if you want to pipe stdout of a process to Slack? You will get bash control characters.

[theBaba]

It does the sane thing when it detects the output is being pipped and doesn't output the color controls.

[dozzie]

Great! Where are my colours in `foo | less -SR' on the terminal?

It's not "the sane thing" to differentiate output on STDOUT's attributes. grep doesn't have the --colour option ternary for nothing.

[cytzol]

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.

[deathanatos]

> 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…

[mathw]

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!

[dozzie]

>> grep doesn't have the --colour option ternary for nothing.

> grep does have `--color=auto`, though, which checks whether you're printing to a terminal or not.

Didn't I say that? Ternary. On, off, detect.

[cytzol]

Oh, I completely missed that word. My bad.

[wildmusings]

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.