[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8f27ad5f-9a9c-3db0-a934-88e1810974f3@digikod.net>
Date: Fri, 9 Jun 2023 15:23:08 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: Jonathan Corbet <corbet@....net>,
Íñigo Huguet <ihuguet@...hat.com>,
ojeda@...nel.org, danny@...ag0n.dev
Cc: masahiroy@...nel.org, jgg@...dia.com, linux-kernel@...r.kernel.org,
joe@...ches.com, linux@...musvillemoes.dk, willy@...radead.org,
mailhol.vincent@...adoo.fr
Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting
On 09/06/2023 09:50, Jonathan Corbet wrote:
> Íñigo Huguet <ihuguet@...hat.com> writes:
>
>> EditorConfig is a specification to define the most basic code formatting
>> stuff, and it's supported by many editors and IDEs, either directly or
>> via plugins, including VSCode/VSCodium, Vim, emacs and more.
>>
>> It allows to define formatting style related to indentation, charset,
>> end of lines and trailing whitespaces. It also allows to apply different
>> formats for different files based on wildcards, so for example it is
>> possible to apply different configs to *.{c,h}, *.py and *.rs.
>>
>> In linux project, defining a .editorconfig might help to those people
>> that work on different projects with different indentation styles, so
>> they cannot define a global style. Now they will directly see the
>> correct indentation on every fresh clone of the project.
>>
>> See https://editorconfig.org
>>
>> Co-developed-by: Danny Lin <danny@...ag0n.dev>
>> Signed-off-by: Danny Lin <danny@...ag0n.dev>
>> Signed-off-by: Íñigo Huguet <ihuguet@...hat.com>
>
> So I must confess to still being really nervous about installing a file
> that will silently reconfigure the editors of everybody working on the
> kernel source; I wish there were a straightforward way to do this as an
> opt-in thing. We're talking about creating a flag-day behavioral change
> for, potentially, thousands of kernel developers. Something tells me
> that we might just hear from a few of them.
>
> I wonder if we should, instead, ship a file like this as something like
> Documentation/process/editorconfig, then provide a "make editorconfig"
> command that installs it in the top-level directory for those who want
> it?
>
> Or perhaps I'm worrying too much?
This is a legitimate concern. :)
A safe approach would be to rename the ".editorconfig" file to something
like ".editorconfig.default" and create ".editorconfig" symlinks in all
(parent) directories where enforcing this rules don't change anything
because the children files are already correctly formatted. Again, a
script (provided in another patch) to check and potentially update such
links would be useful.
Powered by blists - more mailing lists