Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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>``
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Member

@xuhdev xuhdev Jun 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>.

Copy link
Member

@xuhdev xuhdev Jun 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with _ rather than ..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

project_icon (without a .<THEME>) appears to be unspecified. Is that intended?

- Specifies the icon of the project to be used in the Editor. Can only be
specified in root EditorConfig files (``root=true``). Optionally, the target
Editor's Theme can be specified in the key after period sign. If the Theme is
specified in the pair's key, the Editor shall use the specified icon only when
the corresponding Theme is active.

The value must be either the absolute or relative path to the icon file. The relative path
is assumed to be relative to the directory, that hosts this root EditorConfig file.
The image file format and resolution are not specified.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not specified

I think we should at least define a particular minimum that .editorconfig-file authors can expect editors to support.


For any pair, a value of ``unset`` removes the effect of that
pair, even if it has been set before. For example, add ``indent_size =
Expand Down