Introduced the project_icon key #89
Conversation
|
+ Konstantin from JetBrains @kaleev Hey Konstantin! The issue is mostly inspired by Jet Brains's IDEs and their project icons support. To clarify the intention - we want to introduce the key/value pair, that outlines the icon to be used for the project in various themes. So, as far as I know, Jet Brains IDEs are not limited to Light and Dark themes, there are more of them, plus possible community themes as well. So, how does Intelj, for instance, resolves the icon for the current theme? For instance, the Apart from that, it would be great if you'll be able to take a look at specification of the |
| @@ -312,6 +312,16 @@ and the supported values associated with them: | |||
| - Must be specified in the preamble. Set to ``true`` to tell the core | |||
| not to check any higher directory for EditorConfig settings for on the | |||
| current filename. The value is case-insensitive. | |||
| * - ``project_icon.<THEME>`` | |||
There was a problem hiding this comment.
If theme can be any string, it doesn't seem to be cross-editor. Rather, it would be better managed within the settings of the editor.
Do you wanna limit theme to be "dark"/"light"?
There was a problem hiding this comment.
Well, in general, in code editors the dark and light themes are quite common, meaning, pretty much almost every IDE/Editor like JetBrains products, VS, VSCode etc. have light and dark themes.
However, they also do have some custom and various themes. So if the user uses the custom theme, then it is unclear what icon should be used in this case.
We can leave this unspecified, but I am not sure if this is the way we want it to be, because it becomes like a half-way solution...
There was a problem hiding this comment.
Cores should always pass on properties it doesn't recognize so it's OK to say what theme is supported. Plus I think replacing dot with underscore is a better idea since we won't know what kind of corner case we will be hitting with a dot in some core libraries...
There was a problem hiding this comment.
Cores should always pass on properties it doesn't recognize so it's OK to say what theme is supported
I consider this means, that not limiting the concrete themes for editors is okay.
Plus I think replacing dot with underscore is a better idea since we won't know what kind of corner case we will be hitting with a dot in some core libraries
I'm not sure if this is the best option, to be honest. Since theme, in this case is a part of the key that may differ or may absent at all. We already use underscore as a words separator inside a given key: indent_size, indent_style, trim_trailing_whitespace etc.
And in these keys, the _ does not have the same meaning as . has in the case of the project_icon.<theme>.
There was a problem hiding this comment.
Yes, we don't limit. We just state what's supported, and the rest is extension.
Using dot is a risky behavior, because we don't know the underlying implementation of some cores may break. I don't think it's worth to take the risk, given that project_icon_dark also reads good to me. It's not perfect, but also acceptably good.
|
Just make sure you are aware, this must be sent to editorconfig/vote first before merging. |
|
@xuhdev I have a couple of questions in regard to voting:
|
Yes, there's a issue template.
Yes, usually we have discussion done somewhere and then vote on a binary decision. That repo isn't for discussion. |
|
Also this feature runs afoul of the first paragraph of the spec:
It should be probably discussed first, as this introduces extra maintenance burdens, and we already lack manpower. |
Here is the draft of the
project_iconpair. The key/value description is open to discussion.CC: @xuhdev @florianb @cxw42
📚 Documentation preview 📚: https://editorconfig-specification--89.org.readthedocs.build/