Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230601075333.14021-1-ihuguet@redhat.com> <87sfb1oz13.fsf@meer.lwn.net>
In-Reply-To: <87sfb1oz13.fsf@meer.lwn.net>
From:   =?UTF-8?B?w43DsWlnbyBIdWd1ZXQ=?= <ihuguet@redhat.com>
Date:   Fri, 9 Jun 2023 10:49:17 +0200
Message-ID: <CACT4oucYVtGPj+cJrkAKXiwW74VNqb1R3u9jYQ9XnU6-LVde7g@mail.gmail.com>
Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting
To:     Jonathan Corbet <corbet@lwn.net>
Cc:     ojeda@kernel.org, danny@kdrag0n.dev, masahiroy@kernel.org,
        jgg@nvidia.com, mic@digikod.net, linux-kernel@vger.kernel.org,
        joe@perches.com, linux@rasmusvillemoes.dk, willy@infradead.org,
        mailhol.vincent@wanadoo.fr
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Jun 9, 2023 at 9:50=E2=80=AFAM Jonathan Corbet <corbet@lwn.net> wro=
te:
>
> =C3=8D=C3=B1igo Huguet <ihuguet@redhat.com> writes:
>
> > EditorConfig is a specification to define the most basic code formattin=
g
> > 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 differen=
t
> > 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@kdrag0n.dev>
> > Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> > Signed-off-by: =C3=8D=C3=B1igo Huguet <ihuguet@redhat.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 valid option, indeed, but In my opinion we are overlooking this.

Adding an .editorconfig will not silently reconfigure the editors of
everyone because for most editors you need to install a plugin to use
it. In my opinion, that's enough "opt-in". Here is the list of editors
that have built-in support, and those that need a plugin install. I
don't think that those with built-in support are widely used for
kernel development, and many of them allow to disable the feature.

I see this as the exact same case as adding a .clang-format file, as
we already have. Some editors, either built-in or via plugin,
automatically reformat code when this file is present. And it's far
more "intrusive" than editorconfig.

Also, note that, for those with editorconfig enabled in their editors,
the editor would be enforcing formatting rules that are mandatory, not
optional.

Said that, if you still prefer to do it via `make editorconfig`, I can
change it.

>
> Thanks,
>
> jon
>


--=20
=C3=8D=C3=B1igo Huguet