Clarify the case sensitivity of .editorconfig file #70
Conversation
xuhdev
force-pushed
the
case
branch
3 times, most recently
from
d9f42e2 to
b8a11d3
Compare
xuhdev
force-pushed
the
case
branch
3 times, most recently
from
ff915a4 to
2af728e
Compare
index.rst
Outdated
|
|
||
| As noted above, the ``.editorconfig`` filename should be lowercased. On some | ||
| platforms, opening a file with a different capitalization results in opening | ||
| the same file with lowercased file names. On such a platform, a Core may |
There was a problem hiding this comment.
Looks good generally. My only concern is the use of "may", since that is the status-quo behaviour. Could we strengthen it? Maybe:
"On such a platform, the core must ask the operating system for .editorconfig (all-lowercase), and must process any file the operating system provides in response."
That way somebody couldn't write a core that only accepted .editorConfig and claim conformance with this paragraph.
There was a problem hiding this comment.
(I'm also thinking that this subsection should also go to vote -- While we can clarify the lowercase required as we thought they were implicit, as with many other spec document, how Cores should behave on a case-insensitive system is a real change. I can separate this to another PR.)
I improved the wording further more due to it's ambiguity.
I think it's OK to not strengthen this behavior, because users are expected to use all lowercase name, and the rationale to allow a Core to have the said behavior is discussed in the informative paragraph: It is meant to save excessive works from Core. If a Core determines that it's cheap to do so -- I don't know if such a platform exists -- we shouldn't stop them to do so (: What do you think?
Some platforms, such as some cross-platform dynamic programming languages, may introduce unusual behavior to increase portability. They may not be mainstream but by allowing some flexibility here can prevent some implementation difficulties.
Additionally, if some users use .editorConfig, we should probably encourage them to correct that instead of fortify because it will break on some systems.
There was a problem hiding this comment.
how Cores should behave on a case-insensitive system is a real change
That's a fair point. I accept this PR as a description of the status quo. Thanks!
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
.editorconfigfile in a directory, instead of just pointing to the file named.editorconfig.Close editorconfig/editorconfig#523
📚 Documentation preview 📚: https://editorconfig-specification--70.org.readthedocs.build/