Message-ID: <CACT4oudWXa+YPtxHReeMoP6538h=cXJ19MrMhxChUhyfrmuv9w@mail.gmail.com>
Date:   Fri, 9 Jun 2023 10:50:50 +0200
From:   Íñigo Huguet <ihuguet@...hat.com>
To:     Jonathan Corbet <corbet@....net>
Cc:     ojeda@...nel.org, danny@...ag0n.dev, masahiroy@...nel.org,
        jgg@...dia.com, mic@...ikod.net, 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 Fri, Jun 9, 2023 at 10:49 AM Íñigo Huguet <ihuguet@...hat.com> wrote:
>
> On Fri, Jun 9, 2023 at 9:50 AM Jonathan Corbet <corbet@....net> 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 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

Sorry, forgot the link: https://editorconfig.org/

> 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
> >
>
>
> --
> Íñigo Huguet



-- 
Íñigo Huguet

Powered by blists - more mailing lists