[FEATURE] Clarify capitalization of .editorconfig file #523
Comments
|
I've only seen all-lowercase, myself. |
|
I don't think we've ever recognized capital file names. If a filesystem doesn't recognize letter cases, the processes that open the file with a different case will succeed, but I don't think it is our business here to recognize case insensitive names as it will break a lot of existing plugins. This seems like a pretty common pattern among cross-platform programs: directories named |
|
I understand - i think it is more an issue of a file being created on a insensitive fs and eventually being shared with a case sensitive system. My experience with cross-platform applications is that people don't anticipate the usage scenario per se and part of my work is to migrate between systems. As for the example of Git - i am not sure if Git works on every file system (see f.e. this blog post) and for the usage of git, one wouldn't probably migrate the git repo to a case sensitive fs by copying it. I just thought that especially these cross-system applications would be of a special interest for us due to the nature of EditorConfig. I also wouldn't say that this is a breaking change. Yes it would eventually require the plugins to pick the change up but it's not like when this happens it changes anything for most of the people - it would be more of a it just works. But I'm not attached to the change either - I just think it makes sense. |
I don't think it's a breaking change in a semver-MAJOR sense. Semver-MINOR is "add functionality in a backward compatible manner", and that's what recognizing any case would do. On the other hand, how about this? Two devs A and B share a project.
That could be confusing at the very least! |
|
@openjck does VSCode recognize Also, do you happen to have an example of a project using a casing other than all-lowercase? Thanks! |
|
Thanks for the questions. I only just realized EditorConfig support in vscode comes from an extension that appears to be published by the EditorConfig organization itself. I was wrong to say vscode itself was acting one way or the other. I'm not sure that changes anything, but I wanted to clarify that. To answer your first question, it does appear that vscode (with the extension) only supports a mixed-case file (e.g., Here are some public repos I found which use the name |
|
For whatever it's worth, one of the largest repos I see which uses the capitalization |
|
The mentioned project RxSwift also seems to be working primarily on case-insensitive filesystems. To my knowledge, none of the existing core libraries specifically cater case-insensitive I would suggest we add a clarification in the spec: Case sensitivity is often unspelled in a lot of places assuming case-sensitivity, but it doesn't hurt to be more clear. What do you think? |
|
You're right about RxSwift primarily being interesting to Mac developers. At the same time, perhaps not all the repos in the original list would only be likely to receive contributions from developers on a single platform. I myself am on a team where we have some developers on Windows and some (like myself) on Linux. Unfortunately, the name I'm all for clarity, even if the implementation doesn't change. Anything to help devs recognize that naming the file with mixed case is a bad idea if they want devs on Linux, say, to benefit. |
This has been generally assumed since we don't specifically mention other capitalizations. However, some communities seem to have used capital letters in some places, and it's best if we can clarify. If we go the other route, as a standard, the current core libraries would break because they don't work consistently with each other. Besides, core libraries are cumbersome to implement on case-sensitive filesystems, because they always have to use some regex to search a directory. Close editorconfig/editorconfig#523
This has been generally assumed since we don't specifically mention other capitalizations. However, some communities seem to have used capital letters in some places, and it's best if we can clarify. If we go the other route, as a standard, the current core libraries would break because they don't work consistently with each other. Besides, core libraries are cumbersome to implement on case-sensitive filesystems, because they always have to use some regex to search the `.editorconfig` file in a directory, instead of just pointing to the file named `.editorconfig`. Close editorconfig/editorconfig#523
This has been generally assumed since we don't specifically mention other capitalizations, and core libraries have also assumed so. However, some communities seem to have used capital letters in some places, and it's best if we can clarify. If we go the other route, as a standard, the current core libraries would break because they don't work consistently with each other. Additionally, core libraries are cumbersome to implement on case-sensitive filesystems, because they always have to use some regex to search the `.editorconfig` file in a directory, instead of just pointing to the file named `.editorconfig`. Close editorconfig/editorconfig#523
|
I've opened PRs:
@openjck I think the reason probably stems from the authors using case-insensitive filesystems themselves. As far as I know, none of them should be working on a case-sensitive filesystem given the current implementation of all core libraries. I personally had worked cross-platform for a long time and this is a common issue when naming files :/ |
|
I took a look into the proposed change. In my perspective we're currently facing a situation where the current standard cannot be interpreted unambiguously and we try to make it more clear. @xuhdev your proposed change would bring us this definition:
I would like to point out that
I absolutely get your point @xuhdev, but currently we have the situation EditorConfig doesn't work as expected people look into the spec and can't see what's actually wrong. Therefore they can't fix it. In the future EditorConfig might also not work as expected. But now they can look it up and get it fixed. |
This has been generally assumed since we don't specifically mention other capitalizations, and core libraries have also assumed so. However, some communities seem to have used capital letters in some places, and it's best if we can clarify. If we go the other route, as a standard, the current core libraries would break because they don't work consistently with each other. Additionally, core libraries are cumbersome to implement on case-sensitive filesystems, because they always have to use some regex to search the `.editorconfig` file in a directory, instead of just pointing to the file named `.editorconfig`. Close editorconfig/editorconfig#523
|
@florianb I agree, shouldn't have done it before sleeping time 😄 . Looks like I didn't change the right spot. I've made changes with additional details. |
This has been generally assumed since we don't specifically mention other capitalizations, and core libraries have also assumed so. However, some communities seem to have used capital letters in some places, and it's best if we can clarify. If we go the other route, as a standard, the current core libraries would break because they don't work consistently with each other. Additionally, core libraries are cumbersome to implement on case-sensitive filesystems, because they always have to use some regex to search the `.editorconfig` file in a directory, instead of just pointing to the file named `.editorconfig`. Close editorconfig/editorconfig#523
This has been generally assumed since we don't specifically mention other capitalizations, and core libraries have also assumed so. However, some communities seem to have used capital letters in some places, and it's best if we can clarify. If we go the other route, as a standard, the current core libraries would break because they don't work consistently with each other. Additionally, core libraries are cumbersome to implement on case-sensitive filesystems, because they always have to use some regex to search the `.editorconfig` file in a directory, instead of just pointing to the file named `.editorconfig`. Close editorconfig/editorconfig#523
This has been generally assumed since we don't specifically mention other capitalizations, and core libraries have also assumed so. However, some communities seem to have used capital letters in some places, and it's best if we can clarify. If we go the other route, as a standard, the current core libraries would break because they don't work consistently with each other. Additionally, core libraries are cumbersome to implement on case-sensitive filesystems, because they always have to use some regex to search the `.editorconfig` file in a directory, instead of just pointing to the file named `.editorconfig`. Close editorconfig/editorconfig#523
This has been generally assumed since we don't specifically mention other capitalizations, and core libraries have also assumed so. However, some communities seem to have used capital letters in some places, and it's best if we can clarify. If we go the other route, as a standard, the current core libraries would break because they don't work consistently with each other. Additionally, core libraries are cumbersome to implement on case-sensitive filesystems, because they always have to use some regex to search the `.editorconfig` file in a directory, instead of just pointing to the file named `.editorconfig`. Close editorconfig/editorconfig#523
This has been generally assumed since we don't specifically mention other capitalizations, and core libraries have also assumed so. However, some communities seem to have used capital letters in some places, and it's best if we can clarify. If we go the other route, as a standard, the current core libraries would break because they don't work consistently with each other. Additionally, core libraries are cumbersome to implement on case-sensitive filesystems, because they always have to use some regex to search the `.editorconfig` file in a directory, instead of just pointing to the file named `.editorconfig`. Close editorconfig/editorconfig#523
This has been generally assumed since we don't specifically mention other capitalizations, and core libraries have also assumed so. However, some communities seem to have used capital letters in some places, and it's best if we can clarify. If we go the other route, as a standard, the current core libraries would break because they don't work consistently with each other. Additionally, core libraries are cumbersome to implement on case-sensitive filesystems, because they always have to use some regex to search the `.editorconfig` file in a directory, instead of just pointing to the file named `.editorconfig`. Close editorconfig/editorconfig#523
Which problem does this feature fix?
The EditorConfig website states that:
However, the site is not clear about whether capitalization matters. Some tools, like Neovim, do not use files named .editorConfig (notice the capital C), but other editors, like VSCode, do use files named .editorConfig.
edit (2025-01-23): As it turns out, it's not the editor that matters, but whether the filesystem is case-sensitive. See this comment.
Describe the solution you'd like
On the EditorConfig website, please clearly document whether capitalization matters in the name of the .editorconfig file.
The text was updated successfully, but these errors were encountered: