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>
 <8f27ad5f-9a9c-3db0-a934-88e1810974f3@digikod.net> <CACT4oue7DgUf+65yat+6t9VrSji1N0njxunObHbRzfjMCAPmYQ@mail.gmail.com>
 <CAMZ6RqJ66wxVAcveVunQ3W6sYihQM43Hi44D7TAee_nUPk+ZXA@mail.gmail.com>
In-Reply-To: <CAMZ6RqJ66wxVAcveVunQ3W6sYihQM43Hi44D7TAee_nUPk+ZXA@mail.gmail.com>
From:   =?UTF-8?B?w43DsWlnbyBIdWd1ZXQ=?= <ihuguet@redhat.com>
Date:   Wed, 14 Jun 2023 15:04:29 +0200
Message-ID: <CACT4ouc23BYWNBrE7w0a8Huy5hrhaix3=0P3kuXFQhwk_uib1g@mail.gmail.com>
Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting
To:     Vincent MAILHOL <mailhol.vincent@wanadoo.fr>
Cc:     =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= <mic@digikod.net>,
        Jonathan Corbet <corbet@lwn.net>, ojeda@kernel.org,
        danny@kdrag0n.dev, masahiroy@kernel.org, jgg@nvidia.com,
        linux-kernel@vger.kernel.org, joe@perches.com,
        linux@rasmusvillemoes.dk, willy@infradead.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Jun 14, 2023 at 2:55=E2=80=AFPM Vincent MAILHOL
<mailhol.vincent@wanadoo.fr> wrote:
>
> On Wed. 14 Jun. 2023 at 20:40, =C3=8D=C3=B1igo Huguet <ihuguet@redhat.com=
> wrote:
> > On Fri, Jun 9, 2023 at 3:23=E2=80=AFPM Micka=C3=ABl Sala=C3=BCn <mic@di=
gikod.net> wrote:
> > > On 09/06/2023 09:50, Jonathan Corbet wrote:
> > > > =C3=8D=C3=B1igo Huguet <ihuguet@redhat.com> writes:
> > > >
> > > >> EditorConfig is a specification to define the most basic code form=
atting
> > > >> stuff, and it's supported by many editors and IDEs, either directl=
y or
> > > >> via plugins, including VSCode/VSCodium, Vim, emacs and more.
> > > >>
> > > >> It allows to define formatting style related to indentation, chars=
et,
> > > >> end of lines and trailing whitespaces. It also allows to apply dif=
ferent
> > > >> 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 peo=
ple
> > > >> 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 a=
s an
> > > > opt-in thing.  We're talking about creating a flag-day behavioral c=
hange
> > > > 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 editorconf=
ig"
> > > > command that installs it in the top-level directory for those who w=
ant
> > > > it?
> > > >
> > > > Or perhaps I'm worrying too much?
> > >
> > > This is a legitimate concern. :)
> > >
> > > A safe approach would be to rename the ".editorconfig" file to someth=
ing
> > > like ".editorconfig.default" and create ".editorconfig" symlinks in a=
ll
> > > (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 su=
ch
> > > links would be useful.
> > >
> >
> > I can't think of an easy way to create that script. Formatting is done
> > by each editor using the rules from .editorconfig, but I didn't find
> > any available good script or tool to check if a file complies or not.
> > Creating that script is not trivial.
> >
> > I neither think it is good to enable it for some folders and not for
> > others: developers will be surprised of having assistance in some
> > files and not in others, I would be bothered with such inconsistency.
> >
> > Right now I see 2 possibilities:
> > - Provide an .editorconfig.default so those that want to use it, can
> > do it. But I wouldn't mess with cherry-picking directories that
> > already complies and those that don't, just the developer chooses to
> > use it or not, and that's all.
> > - Provide an .editorconfig directly, and those that don't want to use
> > it, either disable it in their editors or manually delete the file.
> >
> > Please tell me what approach you prefer.
>
> Personally, I vote for the latter. My honest opinion is that we are
> putting too much consideration into the risk of rejections.

I completely agree.

> =C3=8D=C3=B1igo previously stated that editors such as Kate can not opt o=
ut. I
> think that the reason is simply that no one has complained about it so
> far. I did some research on the internet with the keyword "kate
> disable editorconfig", and nothing  relevant appeared. A deeper
> research made me found this:

I have not "complained", but I have filled a request just today, that
I think won't reach far: https://bugs.kde.org/show_bug.cgi?id=3D471008

>   KatePart has support for reading configurations from
>   .editorconfig files, when the editorconfig library is
>   installed. KatePart automatically searches for a .editorconfig
>   whenever you open a file. It gives priority to .kateconfig
>   files, though.
>
> source: https://docs.kde.org/stable5/en/kate/katepart/config-variables.ht=
ml
>
> So it appears that for Kate, installing the editorconfig lib is a
> prerequisite. I think it falls in the opt-in category.

I'm not 100% sure, but I think that this is a requisite at build time.
So unless you build Kate from source, it will be built-in without
opt-out choice.

>
> Is there really an editor with default opt-in and no options to
> opt-out? I doubt...

Kate is the only one I have seen so far, but it's difficult to know.

> I really think we should have the .editorconfig at the root and for
> the rare edge cases where the user really wants to opt-out, I
> sincerely believe that there will be solutions. I have seen many
> projects using it and I do not recall push backs or complaints.
>


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