LinuxLists.cc - [PATCH v4] Add .editorconfig file for basic formatting

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Fri, Jun 2, 2023 at 5:37 PM Mickaël Salaün <[email protected]> wrote:
>
> Looks good to me, thanks!
>
> Acked-by: Mickaël Salaün <[email protected]>
>
> It would be nice to have a script to check files and output a diff if
> they are not in line with this configuration. That could also be used to
> measure how many files are compliant with these rules, and add this
> stats in the commit message.

Agreed.

> For some reasons, maintainers may want to exclude some files from these
> constraints. It would be useful to add some documentation explaining how
> to do it.

I would suggest adding it directly as a comment on top of the
`.editorconfig` file itself. Or, at least, put there the link to the
official page (https://editorconfig.org), which mentions `unset`,
assuming that is the way to do so.

Íñigo, I would also suggest sending the patch to Andrew Morton.

Cheers,
Miguel

2023-06-09 08:00:56

by Jonathan Corbet

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

Íñigo Huguet <[email protected]> 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 <[email protected]>
> Signed-off-by: Danny Lin <[email protected]>
> Signed-off-by: Íñigo Huguet <[email protected]>

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?

Thanks,

jon

2023-06-09 08:33:28

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Fri, Jun 9, 2023 at 9:50 AM Jonathan Corbet <[email protected]> wrote:
>
> So I must confess to still being really nervous about installing a file
> that will silently reconfigure the editors of everybody working on the

Yeah, especially given the variety of editors (and plugins for those)
used for kernel development.

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

That would make me less worried indeed. It would also allow to be a
bit more aggressive on introducing some of the unclear file
extensions/rules to test them out first over time.

Cheers,
Miguel

2023-06-09 08:54:52

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Fri, Jun 9, 2023 at 9:50 AM Jonathan Corbet <[email protected]> wrote:
>
> Íñigo Huguet <[email protected]> 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 <[email protected]>
> > Signed-off-by: Danny Lin <[email protected]>
> > Signed-off-by: Íñigo Huguet <[email protected]>
>
> 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
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

2023-06-09 08:55:13

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Fri, Jun 9, 2023 at 10:49 AM Íñigo Huguet <[email protected]> wrote:
>
> On Fri, Jun 9, 2023 at 9:50 AM Jonathan Corbet <[email protected]> wrote:
> >
> > Íñigo Huguet <[email protected]> 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 <[email protected]>
> > > Signed-off-by: Danny Lin <[email protected]>
> > > Signed-off-by: Íñigo Huguet <[email protected]>
> >
> > 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

2023-06-09 11:05:10

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Fri, Jun 9, 2023 at 10:49 AM Íñigo Huguet <[email protected]> wrote:
>
> 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
> don't think that those with built-in support are widely used for
> kernel development, and many of them allow to disable the feature.

It is true that some of the big ones (Emacs, Vim, VS Code...) do not,
but e.g. NeoVim and Kate (`KTextEditor`) both seem to support it, and
those are used by some kernel developers. In particular, NeoVim says
it enables it by default, if I am reading correctly.

But perhaps those two behave as we want.

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

I do not recall any complaints about code getting reformatted
automatically -- which editors are you referring to? (i.e. that
natively reformat the code, in its default configuration).

In any case, it was a slightly more constrained case: `clang-format`
(and LLVM/Clang) needed to be installed with a new enough version,
which may not have been too common back then, and it ""only"" applied
to C code.

Cheers,
Miguel

2023-06-09 13:51:54

by Mickaël Salaün

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On 09/06/2023 09:50, Jonathan Corbet wrote:
> Íñigo Huguet <[email protected]> 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 <[email protected]>
>> Signed-off-by: Danny Lin <[email protected]>
>> Signed-off-by: Íñigo Huguet <[email protected]>
>
> 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.

2023-06-14 11:46:49

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Fri, Jun 9, 2023 at 3:23 PM Mickaël Salaün <[email protected]> wrote:
>
>
> On 09/06/2023 09:50, Jonathan Corbet wrote:
> > Íñigo Huguet <[email protected]> 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 <[email protected]>
> >> Signed-off-by: Danny Lin <[email protected]>
> >> Signed-off-by: Íñigo Huguet <[email protected]>
> >
> > 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.
--
Íñigo Huguet

2023-06-14 11:57:21

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Fri, Jun 9, 2023 at 12:49 PM Miguel Ojeda
<[email protected]> wrote:
>
> On Fri, Jun 9, 2023 at 10:49 AM Íñigo Huguet <[email protected]> wrote:
> >
> > 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
> > don't think that those with built-in support are widely used for
> > kernel development, and many of them allow to disable the feature.
>
> It is true that some of the big ones (Emacs, Vim, VS Code...) do not,
> but e.g. NeoVim and Kate (`KTextEditor`) both seem to support it, and
> those are used by some kernel developers. In particular, NeoVim says
> it enables it by default, if I am reading correctly.
>
> But perhaps those two behave as we want.

As I can see, NeoVim allows to disable it, which is good enough for
me, but Kate doesn't.

>
> > 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.
>
> I do not recall any complaints about code getting reformatted
> automatically -- which editors are you referring to? (i.e. that
> natively reformat the code, in its default configuration).

Maybe not in default configuration, but people might have it enabled
in their editors anyway, so suddenly appearing a .clangformat in the
repo could cause it. My point is that this is a very similar case.

> In any case, it was a slightly more constrained case: `clang-format`
> (and LLVM/Clang) needed to be installed with a new enough version,
> which may not have been too common back then, and it ""only"" applied
> to C code.
>
> Cheers,
> Miguel
>

--
Íñigo Huguet

2023-06-14 12:26:34

by Rasmus Villemoes

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On 14/06/2023 13.40, Íñigo Huguet wrote:

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

So opting out by deleting the file would leave the developer's work-tree
permanently dirty I think. So if there are editors where one cannot
actually disable the editorconfig plug-in, and we worry/care about
those, the second option seems to be a no-go.

The first option works better; we can add an ".editorconfig" entry to
.gitignore, and then have people who want to opt-in make .editorconfig a
symlink to .editorconfig.default.

I definitely agree that we shouldn't try to do anything per directory.

Rasmus

2023-06-14 13:15:05

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Wed, Jun 14, 2023 at 2:55 PM Vincent MAILHOL
<[email protected]> wrote:
>
> On Wed. 14 Jun. 2023 at 20:40, Íñigo Huguet <[email protected]> wrote:
> > On Fri, Jun 9, 2023 at 3:23 PM Mickaël Salaün <[email protected]> wrote:
> > > On 09/06/2023 09:50, Jonathan Corbet wrote:
> > > > Íñigo Huguet <[email protected]> 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 <[email protected]>
> > > >> Signed-off-by: Danny Lin <[email protected]>
> > > >> Signed-off-by: Íñigo Huguet <[email protected]>
> > > >
> > > > 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

2023-06-14 14:23:49

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Wed. 14 Jun. 2023 at 20:40, Íñigo Huguet <[email protected]> wrote:
> On Fri, Jun 9, 2023 at 3:23 PM Mickaël Salaün <[email protected]> wrote:
> > On 09/06/2023 09:50, Jonathan Corbet wrote:
> > > Íñigo Huguet <[email protected]> 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 <[email protected]>
> > >> Signed-off-by: Danny Lin <[email protected]>
> > >> Signed-off-by: Íñigo Huguet <[email protected]>
> > >
> > > 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.

2023-06-15 02:55:08

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Wed. 14 Jun. 2023 at 22:04, Íñigo Huguet <[email protected]> wrote:
> On Wed, Jun 14, 2023 at 2:55 PM Vincent MAILHOL <[email protected]> wrote:
> > On Wed. 14 Jun. 2023 at 20:40, Íñigo Huguet <[email protected]> wrote:

(...)

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

Wow! That's a lot of investment on your side. Clearly, there is no
appetite from the maintainers. But if something needs to be done
(which I doubt), I think it should be on the editor's side rather than
on the project using that .editorconfig file.

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

It seems you are right. On Ubuntu, the "kate" package actually depends
on "libeditorconfig0", so indeed, that's a hard dependency. My bad.

That said, on source based distribution, it should be configurable.
Taking gentoo as an example, you get an editorconfig USEFLAG which
allows to choose whether or not you enable editorconfig during the
compilation:

https://packages.gentoo.org/packages/kde-frameworks/ktexteditor

I continued my investigation. Here is the commit which adds
editorconfig to ktexteditor (used by kate):

https://github.com/KDE/ktexteditor/commit/f9f133b6ac72dfa12bdeeab1a37c5e9dc9a9354e

Looking at what the code does, it first walk through the absolute path
in reverse and if it finds a .kateconfig file, it does an early
return:

https://github.com/KDE/ktexteditor/blob/f9f133b6ac72dfa12bdeeab1a37c5e9dc9a9354e/src/document/katedocument.cpp#L2578

This should act as a kill switch. Not tested, but adding a .kateconfig
seems like a valid opt out method. This is consistent with the
paragraph I quoted in my previous message:

It gives priority to .kateconfig files, though.

Problem solved?

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

2023-06-15 06:46:54

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Thu, Jun 15, 2023 at 4:40 AM Vincent MAILHOL
<[email protected]> wrote:
>
> On Wed. 14 Jun. 2023 at 22:04, Íñigo Huguet <[email protected]> wrote:
> > On Wed, Jun 14, 2023 at 2:55 PM Vincent MAILHOL <[email protected]> wrote:
> > > On Wed. 14 Jun. 2023 at 20:40, Íñigo Huguet <[email protected]> wrote:
>
> (...)
>
> > > > 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
>
> Wow! That's a lot of investment on your side. Clearly, there is no
> appetite from the maintainers. But if something needs to be done
> (which I doubt), I think it should be on the editor's side rather than
> on the project using that .editorconfig file.
>
> > > 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.
>
> It seems you are right. On Ubuntu, the "kate" package actually depends
> on "libeditorconfig0", so indeed, that's a hard dependency. My bad.
>
> That said, on source based distribution, it should be configurable.
> Taking gentoo as an example, you get an editorconfig USEFLAG which
> allows to choose whether or not you enable editorconfig during the
> compilation:
>
> https://packages.gentoo.org/packages/kde-frameworks/ktexteditor
>
> I continued my investigation. Here is the commit which adds
> editorconfig to ktexteditor (used by kate):
>
> https://github.com/KDE/ktexteditor/commit/f9f133b6ac72dfa12bdeeab1a37c5e9dc9a9354e
>
> Looking at what the code does, it first walk through the absolute path
> in reverse and if it finds a .kateconfig file, it does an early
> return:
>
> https://github.com/KDE/ktexteditor/blob/f9f133b6ac72dfa12bdeeab1a37c5e9dc9a9354e/src/document/katedocument.cpp#L2578
>
> This should act as a kill switch. Not tested, but adding a .kateconfig
> seems like a valid opt out method. This is consistent with the
> paragraph I quoted in my previous message:
>
> It gives priority to .kateconfig files, though.
>
> Problem solved?

Very good catch. I have tried and adding an empty .kateconfig file
makes that .editorconfig is ignored. For me this is a simple enough
workaround. We can document it as a comment in the top of
.editorconfig file.

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

2023-10-11 07:37:18

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Thu. 1 June 2023 at 16:53, Íñigo Huguet <[email protected]> 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.
>
> 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 <[email protected]>
> Signed-off-by: Danny Lin <[email protected]>
> Signed-off-by: Íñigo Huguet <[email protected]>
> ---

Is there any news for this patch? I would really love this to become mainstream.

2023-10-23 02:29:14

by Jonathan Corbet

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

Vincent MAILHOL <[email protected]> writes:

> On Thu. 1 June 2023 at 16:53, Íñigo Huguet <[email protected]> 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.
>>
>> 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 <[email protected]>
>> Signed-off-by: Danny Lin <[email protected]>
>> Signed-off-by: Íñigo Huguet <[email protected]>
>> ---
>
> Is there any news for this patch? I would really love this to become mainstream.

I have concerns about this patch that I have expressed in the past.

I'm not going to apply it... since it's a global change that affects all
kernel developers, I don't think I *should* apply it. I would recommend
sending it directly to Linus; if you can get an ack from him, I'll apply
it then.

Thanks,

jon

2023-10-23 06:19:08

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Mon. 23 Oct. 2023 at 11:28, Jonathan Corbet <[email protected]> wrote:
> Vincent MAILHOL <[email protected]> writes:
>
> > On Thu. 1 June 2023 at 16:53, Íñigo Huguet <[email protected]> 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.
> >>
> >> 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 <[email protected]>
> >> Signed-off-by: Danny Lin <[email protected]>
> >> Signed-off-by: Íñigo Huguet <[email protected]>
> >> ---
> >
> > Is there any news for this patch? I would really love this to become mainstream.
>
> I have concerns about this patch that I have expressed in the past.
>
> I'm not going to apply it... since it's a global change that affects all
> kernel developers, I don't think I *should* apply it. I would recommend
> sending it directly to Linus; if you can get an ack from him, I'll apply
> it then.

Hi Jonathan,

Thanks for the comment, message taken.

Hi Íñigo,

The last version of the patch being from you, would you like to bring
the topic to Linus yourself or shall I do it instead?

Yours sincerely,
Vincent Mailhol

2023-10-23 06:27:35

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Mon, Oct 23, 2023 at 8:19 AM Vincent MAILHOL
<[email protected]> wrote:
>
> On Mon. 23 Oct. 2023 at 11:28, Jonathan Corbet <[email protected]> wrote:
> > Vincent MAILHOL <[email protected]> writes:
> >
> > > On Thu. 1 June 2023 at 16:53, Íñigo Huguet <[email protected]> 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.
> > >>
> > >> 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 <[email protected]>
> > >> Signed-off-by: Danny Lin <[email protected]>
> > >> Signed-off-by: Íñigo Huguet <[email protected]>
> > >> ---
> > >
> > > Is there any news for this patch? I would really love this to become mainstream.
> >
> > I have concerns about this patch that I have expressed in the past.
> >
> > I'm not going to apply it... since it's a global change that affects all
> > kernel developers, I don't think I *should* apply it. I would recommend
> > sending it directly to Linus; if you can get an ack from him, I'll apply
> > it then.
>
> Hi Jonathan,
>
> Thanks for the comment, message taken.
>
> Hi Íñigo,
>
> The last version of the patch being from you, would you like to bring
> the topic to Linus yourself or shall I do it instead?

I'm not doing kernel development lately, so please go ahead pushing
this if you want.

Anyway, note that, as discussed in the thread, it is incorrect to say
that it will affect all kernel developers: most IDEs and editors only
have "opt-in" support for editorconfig, and the few that are not
"opt-in", are either "opt-out" or has a workaround (Kate).

>
>
> Yours sincerely,
> Vincent Mailhol
>

--
Íñigo Huguet

2023-12-11 17:53:04

by Masahiro Yamada

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Mon, Oct 23, 2023 at 3:26 PM Íñigo Huguet <[email protected]> wrote:
>
> On Mon, Oct 23, 2023 at 8:19 AM Vincent MAILHOL
> <[email protected]> wrote:
> >
> > On Mon. 23 Oct. 2023 at 11:28, Jonathan Corbet <[email protected]> wrote:
> > > Vincent MAILHOL <[email protected]> writes:
> > >
> > > > On Thu. 1 June 2023 at 16:53, Íñigo Huguet <[email protected]> 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.
> > > >>
> > > >> 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 <[email protected]>
> > > >> Signed-off-by: Danny Lin <[email protected]>
> > > >> Signed-off-by: Íñigo Huguet <[email protected]>
> > > >> ---
> > > >
> > > > Is there any news for this patch? I would really love this to become mainstream.
> > >
> > > I have concerns about this patch that I have expressed in the past.
> > >
> > > I'm not going to apply it... since it's a global change that affects all
> > > kernel developers, I don't think I *should* apply it. I would recommend
> > > sending it directly to Linus; if you can get an ack from him, I'll apply
> > > it then.
> >
> > Hi Jonathan,
> >
> > Thanks for the comment, message taken.
> >
> > Hi Íñigo,
> >
> > The last version of the patch being from you, would you like to bring
> > the topic to Linus yourself or shall I do it instead?
>
> I'm not doing kernel development lately, so please go ahead pushing
> this if you want.
>
> Anyway, note that, as discussed in the thread, it is incorrect to say
> that it will affect all kernel developers: most IDEs and editors only
> have "opt-in" support for editorconfig, and the few that are not
> "opt-in", are either "opt-out" or has a workaround (Kate).

Applied to linux-kbuild. Thanks.

We invested a significant amount of time in research and discussion,
and I do not want to lose our efforts.

If it turns out to be problematic, it is easy to revert it.
(although I do not think so, given the wide adoption in many projects.)

--
Best Regards
Masahiro Yamada

2024-01-23 20:43:39

by Andy Shevchenko

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

Thu, Jun 01, 2023 at 09:53:33AM +0200, ??igo Huguet kirjoitti:
> 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

..

> +[{*.{awk,c,dts,dtsi,dtso,h,mk,s,S},Kconfig,Makefile,Makefile.*}]

Missing Kconfig.* ?

--
With Best Regards,
Andy Shevchenko

2024-06-02 15:31:14

by Mateusz Guzik

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Tue, Dec 12, 2023 at 02:50:59AM +0900, Masahiro Yamada wrote:
> On Mon, Oct 23, 2023 at 3:26 PM Íñigo Huguet <[email protected]> wrote:
> >
> > On Mon, Oct 23, 2023 at 8:19 AM Vincent MAILHOL
> > <[email protected]> wrote:
> > >
> > > On Mon. 23 Oct. 2023 at 11:28, Jonathan Corbet <[email protected]> wrote:
> > > > Vincent MAILHOL <[email protected]> writes:
> > > >
> > > > > On Thu. 1 June 2023 at 16:53, Íñigo Huguet <[email protected]> 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.
> > > > >>
> > > > >> 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 <[email protected]>
> > > > >> Signed-off-by: Danny Lin <[email protected]>
> > > > >> Signed-off-by: Íñigo Huguet <[email protected]>
> > > > >> ---
> > > > >
> > > > > Is there any news for this patch? I would really love this to become mainstream.
> > > >
> > > > I have concerns about this patch that I have expressed in the past.
> > > >
> > > > I'm not going to apply it... since it's a global change that affects all
> > > > kernel developers, I don't think I *should* apply it. I would recommend
> > > > sending it directly to Linus; if you can get an ack from him, I'll apply
> > > > it then.
> > >
> > > Hi Jonathan,
> > >
> > > Thanks for the comment, message taken.
> > >
> > > Hi Íñigo,
> > >
> > > The last version of the patch being from you, would you like to bring
> > > the topic to Linus yourself or shall I do it instead?
> >
> > I'm not doing kernel development lately, so please go ahead pushing
> > this if you want.
> >
> > Anyway, note that, as discussed in the thread, it is incorrect to say
> > that it will affect all kernel developers: most IDEs and editors only
> > have "opt-in" support for editorconfig, and the few that are not
> > "opt-in", are either "opt-out" or has a workaround (Kate).
>
>
>
>
> Applied to linux-kbuild. Thanks.
>
> We invested a significant amount of time in research and discussion,
> and I do not want to lose our efforts.
>
> If it turns out to be problematic, it is easy to revert it.
> (although I do not think so, given the wide adoption in many projects.)
>

So after recently switching to neovim I found that .editorconfig results
in messing up my diffs.

I'm screwing around in the vfs layer which has numerous pre-existing
whitespace issues. neovim proceeds to *silently* whackall of the stray
spaces and whatnot, which you only find out about after you git diff/git
show

You can try yourself by editing fs/dcache.c or fs/bad_inode.c.

It stems from this line:
trim_trailing_whitespace = true

The problem is dodged by setting it to false or adding this to
~/.config/nvim/init.lua:
vim.g.editorconfig = false

Is there a non-giant-hammer method to disable the thing? Maybe some lua
magic to special-case that this is the kernel tree?

Also note editing the shipped config shows as a diff to master, so doing
it is not that great either.

If someone could block new whitespace issues from appearing *and* sorted
out all existing ones, I would have no comments. Definitely not going to
try even myself though.

A naive/shite grep claims 840 .c files with issues:
find . -name '*.c' -print0 | xargs -0 grep -l ' $' | wc -l

As is I think the config mostly gets in the way and most people have a
setup which does not use it (for example my vim does not). Alternatively
maye it is neovim which is overzalous here and other editors don't treat
the entire file. If there is a way to convince the thing to only tend to
whitespace issues in edited lines that would be great.

I think the best way forward for the time being is to move .editorconfig
somewhere (scripts/ even though it is not one?) and leave it there as a
template for interested parties. Then people who insist on using the
config can cp and modify (or not) as needed.

I don't have a strong opinion as long as it buggers off the whitespace I
did not even touch or a solution is given which whacks this aspect, but
only for the Linux repo.

2024-06-02 16:29:12

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Sun, Jun 2, 2024 at 5:31 PM Mateusz Guzik <[email protected]> wrote:
>
> You can try yourself by editing fs/dcache.c or fs/bad_inode.c.
>
> It stems from this line:
> trim_trailing_whitespace = true
>
> The problem is dodged by setting it to false or adding this to
> ~/.config/nvim/init.lua:
> vim.g.editorconfig = false
>
> Is there a non-giant-hammer method to disable the thing? Maybe some lua
> magic to special-case that this is the kernel tree?

It may be possible to disable it for particular folder/patterns and
then try to get their maintainers to do a sweep eventually.

Cheers,
Miguel

2024-06-02 18:28:25

by Joe Perches

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Sun, 2024-06-02 at 18:28 +0200, Miguel Ojeda wrote:
> On Sun, Jun 2, 2024 at 5:31 PM Mateusz Guzik <[email protected]> wrote:
> >
> > You can try yourself by editing fs/dcache.c or fs/bad_inode.c.
> >
> > It stems from this line:
> > trim_trailing_whitespace = true
> >
> > The problem is dodged by setting it to false or adding this to
> > ~/.config/nvim/init.lua:
> > vim.g.editorconfig = false
> >
> > Is there a non-giant-hammer method to disable the thing? Maybe some lua
> > magic to special-case that this is the kernel tree?
>
> It may be possible to disable it for particular folder/patterns and
> then try to get their maintainers to do a sweep eventually.

Not too likely as trailing spaces are all over the tree

Ugly grep:

$ git ls-tree -d -r --name-only HEAD | \
while read dir ; do \
echo -n "$dir " ; git grep -c -h -P "\s$" -- $dir | \
awk '{count += $1} END {print count}'; \
done | \
grep -P " \d+$"
Documentation 1498
Documentation/ABI 1
Documentation/ABI/testing 1
Documentation/PCI 1
Documentation/admin-guide 18
Documentation/admin-guide/aoe 5
Documentation/admin-guide/media 1
Documentation/arch 10
Documentation/arch/arm64 9
Documentation/arch/sparc 1
Documentation/arch/sparc/oradax 1
Documentation/bpf 2
Documentation/core-api 1
Documentation/dev-tools 1
Documentation/devicetree 12
Documentation/devicetree/bindings 12
Documentation/devicetree/bindings/interrupt-controller 6
Documentation/devicetree/bindings/misc 1
Documentation/devicetree/bindings/regulator 3
Documentation/devicetree/bindings/sound 1
Documentation/devicetree/bindings/watchdog 1
Documentation/driver-api 282
Documentation/driver-api/usb 257
Documentation/filesystems 7
Documentation/filesystems/ext4 4
Documentation/filesystems/xfs 1
Documentation/firmware-guide 1
Documentation/firmware-guide/acpi 1
Documentation/firmware_class 1
Documentation/images 7
Documentation/leds 1
Documentation/locking 1
Documentation/maintainer 1
Documentation/mm 1
Documentation/networking 462
Documentation/networking/net_cachelines 460
Documentation/process 2
Documentation/scsi 401
Documentation/sound 183
Documentation/sound/cards 103
Documentation/sound/designs 2
Documentation/sound/hd-audio 10
Documentation/sound/kernel-api 19
Documentation/sound/soc 5
Documentation/sphinx-static 1
Documentation/trace 93
Documentation/translations 3
Documentation/translations/ja_JP 1
Documentation/translations/zh_CN 1
Documentation/translations/zh_CN/admin-guide 1
Documentation/translations/zh_TW 1
Documentation/translations/zh_TW/admin-guide 1
Documentation/usb 5
LICENSES 6
LICENSES/dual 1
LICENSES/preferred 5
arch 4635
arch/alpha 825
arch/alpha/boot 14
arch/alpha/boot/tools 2
arch/alpha/include 77
arch/alpha/include/asm 67
arch/alpha/include/uapi 10
arch/alpha/include/uapi/asm 10
arch/alpha/kernel 711
arch/alpha/lib 19
arch/alpha/math-emu 3
arch/alpha/mm 1
arch/arm 95
arch/arm/boot 10
arch/arm/boot/compressed 8
arch/arm/boot/dts 2
arch/arm/boot/dts/ti 2
arch/arm/boot/dts/ti/omap 2
arch/arm/common 2
arch/arm/include 12
arch/arm/include/asm 8
arch/arm/include/debug 2
arch/arm/include/uapi 2
arch/arm/include/uapi/asm 2
arch/arm/kernel 8
arch/arm/lib 5
arch/arm/mach-ep93xx 2
arch/arm/mach-omap2 1
arch/arm/mach-pxa 1
arch/arm/mach-rpc 5
arch/arm/mach-rpc/include 3
arch/arm/mach-rpc/include/mach 3
arch/arm/mach-s3c 2
arch/arm/mach-sa1100 6
arch/arm/mach-sa1100/include 3
arch/arm/mach-sa1100/include/mach 3
arch/arm/mm 20
arch/arm/nwfpe 18
arch/arm/xen 2
arch/arm64 2
arch/arm64/boot 1
arch/arm64/boot/dts 1
arch/arm64/boot/dts/amlogic 1
arch/arm64/kvm 1
arch/m68k 261
arch/m68k/coldfire 22
arch/m68k/include 236
arch/m68k/include/asm 236
arch/m68k/kernel 1
arch/m68k/lib 1
arch/m68k/mac 1
arch/parisc 2637
arch/parisc/include 81
arch/parisc/include/asm 77
arch/parisc/include/uapi 4
arch/parisc/include/uapi/asm 4
arch/parisc/kernel 1823
arch/parisc/lib 32
arch/parisc/math-emu 699
arch/parisc/mm 2
arch/powerpc 245
arch/powerpc/boot 27
arch/powerpc/boot/dts 8
arch/powerpc/crypto 1
arch/powerpc/include 29
arch/powerpc/include/asm 20
arch/powerpc/include/uapi 9
arch/powerpc/include/uapi/asm 9
arch/powerpc/kernel 116
arch/powerpc/kernel/ptrace 2
arch/powerpc/lib 3
arch/powerpc/mm 1
arch/powerpc/mm/nohash 1
arch/powerpc/perf 1
arch/powerpc/platforms 33
arch/powerpc/platforms/44x 4
arch/powerpc/platforms/chrp 1
arch/powerpc/platforms/maple 2
arch/powerpc/platforms/powermac 15
arch/powerpc/platforms/pseries 11
arch/powerpc/sysdev 2
arch/powerpc/xmon 32
arch/s390 32
arch/s390/include 8
arch/s390/include/asm 5
arch/s390/include/uapi 3
arch/s390/include/uapi/asm 3
arch/s390/kernel 24
arch/sh 62
arch/sh/boards 4
arch/sh/boards/mach-se 1
arch/sh/boards/mach-se/770x 1
arch/sh/boot 1
arch/sh/boot/compressed 1
arch/sh/drivers 1
arch/sh/drivers/dma 1
arch/sh/include 2
arch/sh/include/asm 2
arch/sh/kernel 33
arch/sh/kernel/cpu 26
arch/sh/kernel/cpu/sh2 13
arch/sh/kernel/cpu/sh2a 10
arch/sh/kernel/cpu/sh3 3
arch/sh/lib 17
arch/sparc 244
arch/sparc/crypto 1
arch/sparc/include 45
arch/sparc/include/asm 22
arch/sparc/include/uapi 23
arch/sparc/include/uapi/asm 23
arch/sparc/kernel 123
arch/sparc/lib 42
arch/sparc/math-emu 9
arch/sparc/mm 17
arch/sparc/prom 7
arch/um 51
arch/um/drivers 21
arch/um/include 19
arch/um/include/asm 13
arch/um/include/shared 6
arch/um/kernel 3
arch/um/os-Linux 6
arch/um/os-Linux/drivers 5
arch/x86 134
arch/x86/boot 7
arch/x86/boot/compressed 2
arch/x86/events 1
arch/x86/events/intel 1
arch/x86/include 4
arch/x86/include/asm 4
arch/x86/kernel 5
arch/x86/kernel/acpi 1
arch/x86/lib 49
arch/x86/math-emu 40
arch/x86/mm 5
arch/x86/pci 9
arch/x86/realmode 4
arch/x86/realmode/rm 4
arch/x86/um 8
arch/x86/um/asm 2
arch/x86/um/shared 2
arch/x86/um/shared/sysdep 2
arch/x86/xen 1
arch/xtensa 47
arch/xtensa/kernel 11
arch/xtensa/mm 15
arch/xtensa/variants 21
arch/xtensa/variants/csp 4
arch/xtensa/variants/csp/include 4
arch/xtensa/variants/csp/include/variant 4
arch/xtensa/variants/dc233c 3
arch/xtensa/variants/dc233c/include 3
arch/xtensa/variants/dc233c/include/variant 3
arch/xtensa/variants/de212 4
arch/xtensa/variants/de212/include 4
arch/xtensa/variants/de212/include/variant 4
arch/xtensa/variants/test_kc705_be 6
arch/xtensa/variants/test_kc705_be/include 6
arch/xtensa/variants/test_kc705_be/include/variant 6
arch/xtensa/variants/test_kc705_hifi 4
arch/xtensa/variants/test_kc705_hifi/include 4
arch/xtensa/variants/test_kc705_hifi/include/variant 4
block 17
block/partitions 17
crypto 27
drivers 9947
drivers/acpi 7
drivers/ata 1
drivers/atm 1968
drivers/base 4
drivers/base/regmap 2
drivers/block 83
drivers/bus 2
drivers/cdrom 49
drivers/char 122
drivers/char/agp 1
drivers/char/ipmi 3
drivers/char/mwave 34
drivers/char/tpm 14
drivers/char/xilinx_hwicap 2
drivers/clk 2
drivers/clk/imx 2
drivers/clocksource 3
drivers/connector 1
drivers/cpufreq 10
drivers/cpuidle 1
drivers/crypto 2
drivers/dma 2
drivers/dma/bestcomm 1
drivers/extcon 1
drivers/gpu 3139
drivers/gpu/drm 3139
drivers/gpu/drm/amd 2191
drivers/gpu/drm/amd/amdgpu 20
drivers/gpu/drm/amd/display 4
drivers/gpu/drm/amd/display/dc 4
drivers/gpu/drm/amd/display/dc/dce 2
drivers/gpu/drm/amd/display/dc/dml2 1
drivers/gpu/drm/amd/display/dc/resource 1
drivers/gpu/drm/amd/display/dc/resource/dcn301 1
drivers/gpu/drm/amd/include 1805
drivers/gpu/drm/amd/include/asic_reg 1127
drivers/gpu/drm/amd/include/asic_reg/nbif 1127
drivers/gpu/drm/amd/include/ivsrcid 376
drivers/gpu/drm/amd/include/ivsrcid/dcn 350
drivers/gpu/drm/amd/include/ivsrcid/sdma1 2
drivers/gpu/drm/amd/pm 362
drivers/gpu/drm/amd/pm/powerplay 44
drivers/gpu/drm/amd/pm/powerplay/hwmgr 1
drivers/gpu/drm/amd/pm/powerplay/inc 43
drivers/gpu/drm/amd/pm/powerplay/inc/vega12 5
drivers/gpu/drm/amd/pm/swsmu 318
drivers/gpu/drm/amd/pm/swsmu/inc 317
drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if 299
drivers/gpu/drm/amd/pm/swsmu/smu13 1
drivers/gpu/drm/msm 15
drivers/gpu/drm/msm/dp 2
drivers/gpu/drm/msm/registers 13
drivers/gpu/drm/msm/registers/adreno 1
drivers/gpu/drm/msm/registers/display 1
drivers/gpu/drm/nouveau 7
drivers/gpu/drm/nouveau/include 7
drivers/gpu/drm/nouveau/include/nvrm 7
drivers/gpu/drm/nouveau/include/nvrm/535.113.01 7
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/common 4
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/common/sdk 4
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/common/sdk/nvidia 4
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/common/sdk/nvidia/inc 4
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/common/sdk/nvidia/inc/ctrl 4
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/common/sdk/nvidia/inc/ctrl/ctrla06f 3
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/nvidia 3
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/nvidia/arch 1
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/nvidia/arch/nvalloc 1
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/nvidia/arch/nvalloc/common 1
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/nvidia/arch/nvalloc/common/inc 1
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/nvidia/kernel 2
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/nvidia/kernel/inc 2
drivers/gpu/drm/nouveau/include/nvrm/535.113.01/nvidia/kernel/inc/vgpu 2
drivers/gpu/drm/radeon 926
drivers/hid 36
drivers/hid/usbhid 3
drivers/hwmon 2
drivers/i2c 17
drivers/i2c/busses 16
drivers/iio 3
drivers/iio/dac 1
drivers/iio/gyro 1
drivers/iio/potentiometer 1
drivers/infiniband 4
drivers/infiniband/hw 4
drivers/infiniband/hw/hfi1 2
drivers/infiniband/hw/mlx4 1
drivers/infiniband/hw/qib 1
drivers/input 25
drivers/input/joystick 1
drivers/input/keyboard 2
drivers/input/misc 17
drivers/input/mouse 1
drivers/input/serio 4
drivers/irqchip 1
drivers/macintosh 125
drivers/md 1
drivers/md/bcache 1
drivers/memstick 1
drivers/memstick/core 1
drivers/message 8
drivers/message/fusion 8
drivers/mfd 216
drivers/misc 1
drivers/misc/cxl 1
drivers/mmc 3
drivers/mmc/core 3
drivers/mtd 8
drivers/mtd/maps 1
drivers/mtd/nand 3
drivers/mtd/nand/onenand 2
drivers/mtd/nand/raw 1
drivers/net 658
drivers/net/ethernet 187
drivers/net/ethernet/3com 22
drivers/net/ethernet/8390 95
drivers/net/ethernet/chelsio 5
drivers/net/ethernet/chelsio/cxgb 4
drivers/net/ethernet/chelsio/cxgb3 1
drivers/net/ethernet/dec 4
drivers/net/ethernet/dec/tulip 4
drivers/net/ethernet/fujitsu 36
drivers/net/ethernet/i825xx 3
drivers/net/ethernet/marvell 3
drivers/net/ethernet/marvell/octeon_ep 3
drivers/net/ethernet/seeq 1
drivers/net/ethernet/sfc 2
drivers/net/ethernet/silan 1
drivers/net/ethernet/smsc 12
drivers/net/ethernet/xircom 3
drivers/net/fddi 115
drivers/net/fddi/skfp 115
drivers/net/fddi/skfp/h 34
drivers/net/hamradio 318
drivers/net/wan 20
drivers/net/wireless 18
drivers/net/wireless/ath 1
drivers/net/wireless/ath/ath9k 1
drivers/net/wireless/intel 1
drivers/net/wireless/intel/ipw2x00 1
drivers/net/wireless/ralink 1
drivers/net/wireless/ralink/rt2x00 1
drivers/net/wireless/rsi 11
drivers/net/wireless/ti 4
drivers/net/wireless/ti/wl1251 3
drivers/net/wireless/ti/wlcore 1
drivers/nvme 1
drivers/nvme/host 1
drivers/parisc 323
drivers/parport 46
drivers/pcmcia 92
drivers/platform 4
drivers/platform/x86 4
drivers/pnp 3
drivers/pnp/pnpbios 3
drivers/power 1
drivers/power/supply 1
drivers/powercap 4
drivers/regulator 1
drivers/s390 27
drivers/s390/char 25
drivers/s390/cio 2
drivers/sbus 39
drivers/sbus/char 39
drivers/scsi 1829
drivers/scsi/aacraid 40
drivers/scsi/aic7xxx 170
drivers/scsi/aic7xxx/aicasm 15
drivers/scsi/arcmsr 7
drivers/scsi/arm 18
drivers/scsi/ibmvscsi 30
drivers/scsi/megaraid 7
drivers/scsi/pcmcia 43
drivers/scsi/sym53c8xx_2 789
drivers/soc 1
drivers/soc/bcm 1
drivers/soc/bcm/brcmstb 1
drivers/soc/bcm/brcmstb/pm 1
drivers/staging 2
drivers/staging/rtl8712 1
drivers/staging/rtl8723bs 1
drivers/staging/rtl8723bs/include 1
drivers/target 1
drivers/target/iscsi 1
drivers/tty 300
drivers/tty/hvc 3
drivers/tty/serial 46
drivers/tty/serial/8250 1
drivers/tty/vt 239
drivers/usb 255
drivers/usb/atm 1
drivers/usb/chipidea 1
drivers/usb/class 1
drivers/usb/gadget 1
drivers/usb/host 5
drivers/usb/image 15
drivers/usb/misc 51
drivers/usb/musb 1
drivers/usb/serial 45
drivers/usb/storage 133
drivers/video 509
drivers/video/console 24
drivers/video/fbdev 483
drivers/video/fbdev/aty 109
drivers/video/fbdev/core 1
drivers/video/fbdev/i810 211
drivers/video/fbdev/matrox 91
drivers/video/fbdev/riva 62
drivers/video/logo 2
drivers/xen 3
drivers/xen/events 1
fs 1703
fs/adfs 2
fs/affs 3
fs/befs 90
fs/bfs 3
fs/btrfs 2
fs/cachefiles 1
fs/coda 115
fs/dlm 6
fs/efs 16
fs/ext2 50
fs/freevxfs 18
fs/gfs2 17
fs/hfs 1
fs/hpfs 40
fs/isofs 11
fs/jbd2 1
fs/jffs2 32
fs/lockd 5
fs/nfs 30
fs/nfs/flexfilelayout 1
fs/nfsd 32
fs/nls 1006
fs/ocfs2 7
fs/ocfs2/cluster 1
fs/omfs 1
fs/openpromfs 2
fs/proc 12
fs/qnx4 5
fs/reiserfs 5
fs/smb 1
fs/smb/client 1
fs/sysv 12
fs/ubifs 1
fs/ufs 114
fs/xfs 1
include 785
include/crypto 9
include/crypto/internal 3
include/linux 223
include/linux/byteorder 1
include/linux/fsl 1
include/linux/fsl/bestcomm 1
include/linux/isdn 5
include/linux/mfd 2
include/linux/sunrpc 8
include/math-emu 20
include/net 40
include/net/sctp 6
include/scsi 18
include/sound 82
include/trace 4
include/trace/events 4
include/uapi 329
include/uapi/asm-generic 4
include/uapi/drm 1
include/uapi/linux 311
include/uapi/linux/isdn 3
include/uapi/linux/netfilter 2
include/uapi/linux/netfilter_bridge 4
include/uapi/linux/netfilter_ipv4 1
include/uapi/linux/netfilter_ipv6 3
include/uapi/linux/nfsd 1
include/uapi/linux/tc_act 2
include/uapi/sound 7
include/uapi/xen 6
include/video 58
include/xen 2
include/xen/interface 2
include/xen/interface/hvm 1
init 1
kernel 6
kernel/rcu 1
kernel/trace 2
lib 47
lib/fonts 5
lib/zlib_deflate 12
lib/zlib_inflate 2
mm 2
net 9
net/bluetooth 1
net/ipv4 1
net/mac80211 1
net/netfilter 6
net/netfilter/ipset 1
net/netfilter/ipvs 5
samples 1
samples/connector 1
scripts 21
scripts/gcc-plugins 1
scripts/kconfig 17
scripts/kconfig/tests 17
scripts/kconfig/tests/auto_submenu 7
scripts/kconfig/tests/choice 8
scripts/kconfig/tests/new_choice_with_dep 2
security 4
security/apparmor 1
sound 2833
sound/aoa 3
sound/aoa/fabrics 1
sound/aoa/soundbus 1
sound/core 254
sound/core/oss 56
sound/core/seq 114
sound/core/seq/oss 19
sound/drivers 178
sound/drivers/mpu401 4
sound/drivers/opl3 31
sound/drivers/vx 36
sound/i2c 18
sound/i2c/other 6
sound/isa 366
sound/isa/ad1816a 7
sound/isa/ad1848 1
sound/isa/cs423x 24
sound/isa/es1688 12
sound/isa/gus 35
sound/isa/opti9xx 22
sound/isa/sb 51
sound/isa/wavefront 177
sound/oss 2
sound/oss/dmasound 2
sound/parisc 62
sound/pci 1824
sound/pci/ac97 79
sound/pci/ali5451 54
sound/pci/au88x0 37
sound/pci/ca0106 88
sound/pci/cs46xx 447
sound/pci/cs5535audio 9
sound/pci/echoaudio 11
sound/pci/emu10k1 168
sound/pci/hda 16
sound/pci/ice1712 60
sound/pci/korg1212 12
sound/pci/mixart 27
sound/pci/nm256 19
sound/pci/riptide 10
sound/pci/rme9652 63
sound/pci/trident 201
sound/pci/vx222 3
sound/pci/ymfpci 33
sound/pcmcia 18
sound/pcmcia/pdaudiocf 11
sound/pcmcia/vx 7
sound/ppc 23
sound/sh 1
sound/soc 40
sound/soc/bcm 2
sound/soc/cirrus 1
sound/soc/codecs 35
sound/soc/sh 1
sound/synth 18
sound/synth/emux 18
sound/usb 6
tools 151
tools/bootconfig 2
tools/bootconfig/samples 2
tools/include 15
tools/include/uapi 15
tools/include/uapi/linux 15
tools/perf 34
tools/perf/Documentation 9
tools/perf/scripts 1
tools/perf/scripts/perl 1
tools/perf/scripts/perl/Perf-Trace-Util 1
tools/perf/tests 16
tools/perf/trace 3
tools/perf/trace/beauty 3
tools/perf/trace/beauty/include 2
tools/perf/trace/beauty/include/uapi 2
tools/perf/trace/beauty/include/uapi/linux 2
tools/perf/util 3
tools/power 57
tools/power/cpupower 56
tools/power/cpupower/bench 1
tools/power/cpupower/debug 2
tools/power/cpupower/debug/i386 2
tools/power/cpupower/man 50
tools/power/cpupower/utils 2
tools/power/cpupower/utils/helpers 1
tools/power/pm-graph 1
tools/power/pm-graph/config 1
tools/testing 36
tools/testing/ktest 7
tools/testing/ktest/examples 5
tools/testing/selftests 29
tools/testing/selftests/alsa 1
tools/testing/selftests/arm64 3
tools/testing/selftests/arm64/fp 3
tools/testing/selftests/bpf 3
tools/testing/selftests/bpf/prog_tests 1
tools/testing/selftests/bpf/progs 1
tools/testing/selftests/ftrace 3
tools/testing/selftests/ftrace/test.d 3
tools/testing/selftests/ftrace/test.d/ftrace 3
tools/testing/selftests/kvm 1
tools/testing/selftests/kvm/x86_64 1
tools/testing/selftests/net 15
tools/testing/selftests/net/netfilter 13
tools/testing/selftests/net/openvswitch 1
tools/testing/selftests/rcutorture 2
tools/testing/selftests/rcutorture/bin 2
tools/testing/selftests/x86 1
tools/virtio 7
tools/virtio/linux 1
tools/virtio/ringtest 4

2024-06-03 12:19:51

by Jason Gunthorpe

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Sun, Jun 02, 2024 at 05:30:51PM +0200, Mateusz Guzik wrote:

> As is I think the config mostly gets in the way and most people have a
> setup which does not use it (for example my vim does not). Alternatively
> maye it is neovim which is overzalous here and other editors don't treat
> the entire file. If there is a way to convince the thing to only tend to
> whitespace issues in edited lines that would be great.

Yes, I think that is quite overzealous, I'd view it as a vim issue.

Jason

2024-06-03 12:52:40

by Mateusz Guzik

[permalink] [raw]

Subject: Re: [PATCH v4] Add .editorconfig file for basic formatting

On Mon, Jun 3, 2024 at 2:18 PM Jason Gunthorpe <[email protected]> wrote:
>
> On Sun, Jun 02, 2024 at 05:30:51PM +0200, Mateusz Guzik wrote:
>
> > As is I think the config mostly gets in the way and most people have a
> > setup which does not use it (for example my vim does not). Alternatively
> > maye it is neovim which is overzalous here and other editors don't treat
> > the entire file. If there is a way to convince the thing to only tend to
> > whitespace issues in edited lines that would be great.
>
> Yes, I think that is quite overzealous, I'd view it as a vim issue.
>

I don't know about vim specifically, it was neovim here, for the record.

Anyhow I put on latex gloves and typed in "apt install emacs", added
the plugin as documented on github
(https://github.com/editorconfig/editorconfig-emacs + entries to
.emacs.d/init.el) and got precisely the same behavior.

There is no way I'm trying to other editors.

At this point I suspect this *is* the intended behavior and other
people don't run into it because their editor does not look at
.editorconfig to begin with.

Note my vim does not either, I only ran into it after experimenting with neovim.

--
Mateusz Guzik <mjguzik gmail.com>

2024-06-03 13:41:20