[themes] provide a setting to never show custom language icons

[texastoland]

#140047 introduced custom language icons. Although neat they override file icon themes by default. AFAIK the only way to prevent that behavior is to add showLanguageModeIcons: false (like https://github.com/lineville/vscode-emoji-icons/blob/8e6cdc77686316dcdcd8b6142542299310ccd971/file-icons/emoji-icon-theme.json#L2) to each theme itself. The problem arises that many themes (like https://github.com/EliverLara/sweet-vscode-icons) are unmaintained. I'd like it to be user toggle-able. Related to nushell/vscode-nushell-lang#176.

[aeschli]

Custom language icons do NOT override icon themes. The language default icons are only shown if the file icon theme has no icon for that language except a generic file icon.
If the file icon theme covers the language in the property languageId or even has an icon for the file name or extension you will not see that icon.
I think most file icons profit from having an additional icon showing and showLanguageModeIcons: false is only needed for themes that have such a unique style so that having a icon of a different look is out of place.

I personally don't think we need another setting. Such a setting would have to be theme specific, adding to the complexity.

[texastoland]

Custom language icons do NOT override icon themes.

I understand but they're injecting themselves in my icon themes and I can't override it (without forking).

showLanguageModeIcons: false is only needed for themes that have such a unique style so that having a icon of a different look is out of place.

That strikes the crux of why I opened an issue. File icon themes could be categorized 2 ways: a kitchen sync approach (anything with Material in the name) or a specific aesthetic like the 1 linked originally:

The problem arises that many themes (like EliverLara/sweet-vscode-icons) are unmaintained.

I acknowledge the most popular file icon themes take the grab bag approach. But both (excellent) default themes arguably take the stylistic approach. I do not think the team's decision to show extension icons by default was disagreeable.

I personally don't think we need another setting.

I didn't originally suggest a setting because I was focusing on my XY issue. In my ideal scenario there would be something like:

"icons.associations": {
  "*.nu": "file.sh" // rematch on dummy file name
}

Or even reuse files.associations:

"files.associations": {
  "*.nu": {
    "language": "nushell",
    "icon": "file.sh"
  }
}

That said I strongly empathize with fewer settings both from a user and maintenance perspective. Feel free to close if not wanted.

[aeschli]

Even if you think a theme is not maintained, don't forget to create an issue or, even better, a PR. In the end, having the theme updated is the best solution for everyone.

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[texastoland]

Even if you think a theme is not maintained, don't forget to create an issue or, even better, a PR. In the end, having the theme updated is the best solution for everyone.

To be clear it's been 2 years since your change and very few icon packs I tried implemented it. The decision to effectively allow language extensions to override user preferences means the only solution (other than hate how it looks) is to publish clones with a single line change. But the Marketplace is already inundated with extensions like that. Another alternative could be changing the default?

[vscodenpa]

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodenpa]

🙁 In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.

Happy Coding!