Exa: Many useful ANSI codes do not work with exa

[s-hamann]

Unlike some versions of ls, the given ANSI values must be valid colour codes: exa won't just print out whichever characters are given. The codes accepted by exa are [very basic codes]

I'm sure there is a reasoning behind this, but I fail to understand it. The way it is, exa misses out on lots of useful ANSI codes, some of which I actually use in my $LS_COLORS.
An example is missing support for 24 bit colours, as mentioned in #339. But there is so much more. Here's a non-exhaustive list of code I miss (and that are actually supported by my terminal). Others may make a case for even more codes.

• faint text (2)
• italics (3)
• crossed-out (9)
• background-colours (40-47)
• non-bold bright colours (90-97)
• bright background colours (100-107)
• 256 colour background colours (48;5;nnn)
• 24 bit colours (38;2;rrr:ggg:bbb)
• 24 bit background colours (48;2;rrr:ggg:bbb)

Could this be implemented? Does that need to be implemented at all, or is it simply a matter of dropping that filter for known ANSI codes and handing the responsibility for picking correct codes to the user?

[BrendanLeber]

Agreed. exa is nice but without this the output is unreadable on my system.

[AntonioND]

I use the codes between 90-107 for ls. Even if I switched to 256, it doesn't seem like it would make any difference...

I'm using LS_COLORS so that the output of ls and the colors used for completion in zsh are the same. In exa, with this behaviour, many files look plain white.

Can't you just pass the sequences to the output blindly, or even ignore LS_COLORS? It would be better to just pass the sequences, but even ignoring LS_COLORS completely would be better.

https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters

[ogham]

Hi all, sorry for the late reply on this issue.

I'm sure there is a reasoning behind this, but I fail to understand it.

There's no technical reason why adding these extra codes is impossible — it's merely a matter of adding them, which I'm certainly willing to do.

What's annoying is the way exa's theming works at the moment. Instead of blindly copying the bytes like what was suggested, it parses the ANSI codes into a list of attributes, and then redundantly _un_-parses them to print them out again. This means that exa needs to know what a code means in order to display it.

I'm kind of hoping that by adding the missing styles (italic, faint, strikethrough, etc) and 256-bit colour, I'll have covered enough of the use cases here.

[ogham]

256-bit colour

heh, you know what I mean

[ogham]

Having considered it a bit more, I think the eventual solution _should_ be to stop trying to parse the ANSI codes at all, and instead just find a way to copy the strings into the output without understanding them. This attitude mostly comes from seeing how fiddly the 24-bit colour codes are to parse.

For now, I’ve added support for most of the ones people were missing: