Message-ID: <CAMZ6RqJ66wxVAcveVunQ3W6sYihQM43Hi44D7TAee_nUPk+ZXA@mail.gmail.com>
Date:   Wed, 14 Jun 2023 21:53:46 +0900
From:   Vincent MAILHOL <mailhol.vincent@...adoo.fr>
To:     Íñigo Huguet <ihuguet@...hat.com>
Cc:     Mickaël Salaün <mic@...ikod.net>,
        Jonathan Corbet <corbet@....net>, ojeda@...nel.org,
        danny@...ag0n.dev, masahiroy@...nel.org, jgg@...dia.com,
        linux-kernel@...r.kernel.org, joe@...ches.com,
        linux@...musvillemoes.dk, willy@...radead.org
Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Wed. 14 Jun. 2023 at 20:40, Íñigo Huguet <ihuguet@...hat.com> wrote:
> On Fri, Jun 9, 2023 at 3:23 PM Mickaël Salaün <mic@...ikod.net> wrote:
> > 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.
> >
>
> 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.

Íñigo previously stated that editors such as Kate can not opt out. 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:

  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.html

So it appears that for Kate, installing the editorconfig lib is a
prerequisite. I think it falls in the opt-in category.

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

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.

Powered by blists - more mailing lists