README about fileicons

[braver]

That's no longer true. With a look at syntaxes folder of this package it provides "aliases", too.

Sure, but only for archive-like file formats that cannot be edited in Sublime Text.

The reason for A File Icon's runtime code is to provide patches for all themes instead of just supporting the Default ones.

I’m well aware of that. And there isn’t much against that. But it also isn’t required for users that do only use the default themes.

A lot of that README was written ages ago, well before you were involved with A File Icon. My memory of the early versions of it were that quite some shenanigans were involved to make it all work. Even the name of the package itself is a “hack” to make it load early. I guess a lot of it isn’t true in the same way anymore, and it’s all fair game anyway. But this implementation of the same idea still is more light weight in a way that I prefer (especially when it comes to the “aliases” and output into the packages dir).

So please don’t read that README as an attack on the A File Icon package. I used that for a while too and if it didn’t exist FileIcons wouldn’t either.

[deathaxe]

The readme shouldn't tell lies anyway!

[braver]

You're right of course, but I believe now it's correct. This package doesn't introduce alias languages like the variations on JavaScript it mentions (ie. syntaxes for editable files that people will actually see and case about), even though it does introduce some variations for binary files where the language really doesn't matter. I feel like that's a bit too detailed for a README and the point it makes is still valid. It's maybe a lie in the way most marketing is a lie, ie. it simplifies maybe a bit too much 😄 If you have a suggestion for a change here though, that's totally welcome.