Message-ID: <CACT4ouc23BYWNBrE7w0a8Huy5hrhaix3=0P3kuXFQhwk_uib1g@mail.gmail.com>
Date:   Wed, 14 Jun 2023 15:04:29 +0200
From:   Íñigo Huguet <ihuguet@...hat.com>
To:     Vincent MAILHOL <mailhol.vincent@...adoo.fr>
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, Jun 14, 2023 at 2:55 PM Vincent MAILHOL
<mailhol.vincent@...adoo.fr> wrote:
>
> 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.

I completely agree.

> Íñ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:

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=471008

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

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


-- 
Íñigo Huguet

Powered by blists - more mailing lists