On Wed, Mar 24, 2021 at 8:01 PM Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx> wrote: > > On 03/07/2020 14.29, Jonathan Corbet wrote: > > [doing a bit of necromancy here] > > > On Fri, 3 Jul 2020 00:31:43 -0700 > > Danny Lin <danny@xxxxxxxxxxx> wrote: > > > >> EditorConfig is a standard for defining basic editor configuration in > >> projects. There is support available for 47 code editors as of writing, > >> including both built-in and extension support. Many notable projects > >> have adopted the standard already, including zsh, htop, and qemu. > >> > >> While this isn't a full-fledged C code style specifier, it does set some > >> basic ground rules that make it more convenient for contributors to use > >> any editor of their choice and not have to worry about indentation, line > >> endings, encoding, final newlines, etc. This should make it > >> significantly easier to conform to the kernel's general code style when > >> used in combination with clang-format. > >> > >> For more information, check the official EditorConfig website: > >> https://editorconfig.org/ > >> > >> Signed-off-by: Danny Lin <danny@xxxxxxxxxxx> > >> --- > > > > So I worry a bit that not everybody will welcome the addition of a dotfile > > that may be magically interpreted by their editor. > > I would suppose that one would have to enable editorconfig support > explicitly in one's editor, so this would have no effect for people that > haven't done so (though there are almost certainly exceptions). > > > I also worry that the > > file itself could become a battleground for people wanting to argue about > > style issues. > > I don't think so, not any more than the coding-style document is, and > that seems to be pretty solid (but as doc maintainer, you'd know better). > > > > > Perhaps I worry a bit too much...? > > As someone who regularly needs to submit patches to random upstream > projects to fix bugs or implement minor features, I for one would really > welcome more widespread use of editorconfig. While I mostly work with > the linux kernel (and other projects using the same C style), so my > default C style setting is "linux", even for the kernel this would be > helpful to me when I poke around in none-C files (shell scripts, for > example). > > Rasmus Just from my curiosity, I just checked the behavior when the language is specified by a shebang line. For example, scripts/diffconfig has no file suffix, but specifies '#!/usr/bin/env python3' at the very top line. This is sensible for tools that interface to users. Users have no interest in which language is used internally. As far as I test this patch on Emacs, it follows the rule of [*] rather than [*.{pl,pm,py,tc,json,tc}]. This is the correct behavior but not what we want in general. I do not mean I am negative to this patch. Rather, I very much like this patch, but I just wondered how this case could be handled. I found this: https://github.com/editorconfig/editorconfig/issues/404 I did not read through it, though. -- Best Regards Masahiro Yamada
