customFileTypes not recognized although use custome file-types is active

[homer3018]

Hello there,

I've just gone and added a couple of extension that I want the grammar to be recognized as text.xml.

I've added these lines to my config

    customFileTypes:
      "text.xml": [
        "ssapp"
        "ssdef"
      ]

The syntax color works as expected after that (upon restarting atom).
However even upon restarting atom multiple times, I'm still missing the icons on the LHS and just see the sort of white square as the icon for these files, and the option in file-icons package to use custom file-types, as mentioned in the issue title, is active. I've toggled it just to make sure but nothing changes.

It might very well be on me and if so I apologize in advance :)
But how to fix this though if it is ?

Thanks

[John Gardner]

TL;DR:

Add this to your stylesheet:

.icon[data-name$=".ssapp"]::before,
.icon[data-name$=".ssdef"]::before{
	font: 16px "Octicons Regular";
	content: "\f05f";
	top: 1px;
	
	body.file-icons-coloured & {
		color: #6a9fb5;
	}
}

This replicates the icon assigned to ordinary XML files, which is a generic <> icon used for every other format that doesn
t have a more useful/specific icon.

Rambling explanation you can skip if you don't care why this is happening:

A handful of filetypes—such as XML, text, and YAML—are intentionally excluded from this strategy. The reason is because they're commonly used for project configs that have a more specific icon/logo.

Now, many of these configs don't bother using their format's file extension, resulting in a big mess of filenames that Atom's grammars don't recognise:

Random examples I plucked from config.cson:

.alexrc
.csslintrc
.firebaserc
.htmlhintrc
.huskyrc
.inputrc
.lintstagedrc
.luacheckrc
.nanorc
.nvmrc
.octaverc
.prc
.proselintrc
.sbclrc
.sentryclirc
.unibeautifyrc
.wgetrc

Because it's likely that users will have to assign grammars manually when editing these unregistered filetypes, many icons would revert to something more generic when overridden.

The underlying problem is that the package's database has no concept of "related filetypes". In other words, it has no idea that package.json is actually a JSON file, simply because ther last 5 characters are the same.

More recently, I've been adding explicit references to "parent" formats in the form of a (currently unused) uses field. But with 7,373 lines of densely-packed filetypes… well, you can see why I've not made much progress on this issue. 😉

Don't worry, you're in good company. 😉 This bugs me too, and I've nobody to blame for this but myself 😀).

[homer3018]

got it thank you :)

thanks for the quick reply !