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: <20230404075540.14422-1-ihuguet@redhat.com>
In-Reply-To: <20230404075540.14422-1-ihuguet@redhat.com>
From:   Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date:   Tue, 4 Apr 2023 11:51:41 +0200
Message-ID: <CANiq72mkORtWGuCZBdTy8eEuf9jAtkvA63nnw47MUkREp+j6YA@mail.gmail.com>
Subject: Re: [PATCH v2] Add .editorconfig file for basic formatting
To:     =?UTF-8?B?w43DsWlnbyBIdWd1ZXQ=?= <ihuguet@redhat.com>,
        Danny Lin <danny@kdrag0n.dev>
Cc:     ojeda@kernel.org, masahiroy@kernel.org, jgg@nvidia.com,
        mic@digikod.net, linux-kernel@vger.kernel.org,
        Jonathan Corbet <corbet@lwn.net>,
        Joe Perches <joe@perches.com>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Matthew Wilcox <willy@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Hi =C3=8D=C3=B1igo,

On Tue, Apr 4, 2023 at 9:55=E2=80=AFAM =C3=8D=C3=B1igo Huguet <ihuguet@redh=
at.com> wrote:
>
> 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.

Please see https://lore.kernel.org/lkml/20200703073143.423557-1-danny@kdrag=
0n.dev/
for a previous patch & discussion, as well as commit fa60ce2cb450
("treewide: remove editor modelines and cruft") for a related cleanup.
Cc'ing those that gave some feedback back then.

Danny's v2 patch has some extra extensions/languages it manages as
well as some docs, and yours handles things that one doesn't, like the
Rust files and `Makefile.*` cases. So it would be nice to get a
version that merges everything from both of you, likely as
co-developers.

It still remains important to see if somebody's workflow could break
due to this, especially for the catch-all section `[*]` and for
options like `trim_trailing_whitespace` which can actually break
things like patch files as you note in the changelog. Perhaps landing
it in linux-next for an extended period of time (e.g. a few kernel
cycles) is one way to find out, or we could start without the
"dangerous" options. What do others think?

By the way, for the next/merged version, in your side please keep
`!.editorconfig` sorted and in the other side please avoid the
duplicated `.tc` case (which I just noticed).

Cheers,
Miguel