.editorconfig | 32 ++++++++++++++++++++++++++ .gitignore | 1 + Documentation/process/4.Coding.rst | 4 ++++ Documentation/process/coding-style.rst | 4 ++++ 4 files changed, 41 insertions(+) create mode 100644 .editorconfig
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@kdrag0n.dev>
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
---
v2:
- added special rule for patch files so it doesn't remove
trailing whitespaces, making them unusable.
v3:
- moved all rules from [*] section to all the individual
sections so they doesn't affect to unexpected files.
- added some extensions and files from a patch from Danny
Lin that didn't get to be merged:
https://lore.kernel.org/lkml/20200703073143.423557-1-danny@kdrag0n.dev/
However, the following file types hasn't been added
because they don't have a clear common style:
rst,pl,cocci,tc,bconf,svg,xsl,manual pages
v4:
- Analyzed with a script the styles used by different file types
- Added rules for awd, dts, dtsi, dtso, s, S
- Removed rules for rb and pm that has very few files in the tree
- Removed rules for tools/perf/scripts/*/bin/*
- Changed rules for py to better match the 2 styles that are present in
the tree: 4 spaces by default and tabs for files in subdirectories
tools/{perf,power,rcu,testing/kunit}
---
.editorconfig | 32 ++++++++++++++++++++++++++
.gitignore | 1 +
Documentation/process/4.Coding.rst | 4 ++++
Documentation/process/coding-style.rst | 4 ++++
4 files changed, 41 insertions(+)
create mode 100644 .editorconfig
diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index 000000000000..854773350cc5
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+root = true
+
+[{*.{awk,c,dts,dtsi,dtso,h,mk,s,S},Kconfig,Makefile,Makefile.*}]
+charset = utf-8
+end_of_line = lf
+trim_trailing_whitespace = true
+insert_final_newline = true
+indent_style = tab
+indent_size = 8
+
+[*.{json,py,rs}]
+charset = utf-8
+end_of_line = lf
+trim_trailing_whitespace = true
+insert_final_newline = true
+indent_style = space
+indent_size = 4
+
+# this must be below the general *.py to overwrite it
+[tools/{perf,power,rcu,testing/kunit}/**.py,]
+indent_style = tab
+indent_size = 8
+
+[*.yaml]
+charset = utf-8
+end_of_line = lf
+trim_trailing_whitespace = unset
+insert_final_newline = true
+indent_style = space
+indent_size = 2
diff --git a/.gitignore b/.gitignore
index 70ec6037fa7a..e4b3fe1d029b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -100,6 +100,7 @@ modules.order
#
!.clang-format
!.cocciconfig
+!.editorconfig
!.get_maintainer.ignore
!.gitattributes
!.gitignore
diff --git a/Documentation/process/4.Coding.rst b/Documentation/process/4.Coding.rst
index 1f0d81f44e14..c2046dec0c2f 100644
--- a/Documentation/process/4.Coding.rst
+++ b/Documentation/process/4.Coding.rst
@@ -66,6 +66,10 @@ for aligning variables/macros, for reflowing text and other similar tasks.
See the file :ref:`Documentation/process/clang-format.rst <clangformat>`
for more details.
+Some basic editor settings, such as indentation and line endings, will be
+set automatically if you are using an editor that is compatible with
+EditorConfig. See the official EditorConfig website for more information:
+https://editorconfig.org/
Abstraction layers
******************
diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 007e49ef6cec..ec96462fa8be 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -735,6 +735,10 @@ for aligning variables/macros, for reflowing text and other similar tasks.
See the file :ref:`Documentation/process/clang-format.rst <clangformat>`
for more details.
+Some basic editor settings, such as indentation and line endings, will be
+set automatically if you are using an editor that is compatible with
+EditorConfig. See the official EditorConfig website for more information:
+https://editorconfig.org/
10) Kconfig configuration files
-------------------------------
--
2.39.2
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
On Thu. 1 June 2023 at 16:53, Íñigo Huguet <ihuguet@redhat.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.
>
> 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@kdrag0n.dev>
> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
> ---
Is there any news for this patch? I would really love this to become mainstream.
Vincent MAILHOL <mailhol.vincent@wanadoo.fr> writes:
> On Thu. 1 June 2023 at 16:53, Íñigo Huguet <ihuguet@redhat.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.
>>
>> 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@kdrag0n.dev>
>> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
>> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
>> ---
>
> 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
On Mon. 23 Oct. 2023 at 11:28, Jonathan Corbet <corbet@lwn.net> wrote:
> Vincent MAILHOL <mailhol.vincent@wanadoo.fr> writes:
>
> > On Thu. 1 June 2023 at 16:53, Íñigo Huguet <ihuguet@redhat.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.
> >>
> >> 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@kdrag0n.dev>
> >> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> >> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
> >> ---
> >
> > 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
On Mon, Oct 23, 2023 at 8:19 AM Vincent MAILHOL
<mailhol.vincent@wanadoo.fr> wrote:
>
> On Mon. 23 Oct. 2023 at 11:28, Jonathan Corbet <corbet@lwn.net> wrote:
> > Vincent MAILHOL <mailhol.vincent@wanadoo.fr> writes:
> >
> > > On Thu. 1 June 2023 at 16:53, Íñigo Huguet <ihuguet@redhat.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.
> > >>
> > >> 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@kdrag0n.dev>
> > >> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> > >> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
> > >> ---
> > >
> > > 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
On Mon, Oct 23, 2023 at 3:26 PM Íñigo Huguet <ihuguet@redhat.com> wrote:
>
> On Mon, Oct 23, 2023 at 8:19 AM Vincent MAILHOL
> <mailhol.vincent@wanadoo.fr> wrote:
> >
> > On Mon. 23 Oct. 2023 at 11:28, Jonathan Corbet <corbet@lwn.net> wrote:
> > > Vincent MAILHOL <mailhol.vincent@wanadoo.fr> writes:
> > >
> > > > On Thu. 1 June 2023 at 16:53, Íñigo Huguet <ihuguet@redhat.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.
> > > >>
> > > >> 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@kdrag0n.dev>
> > > >> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> > > >> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
> > > >> ---
> > > >
> > > > 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
On Tue, Dec 12, 2023 at 02:50:59AM +0900, Masahiro Yamada wrote:
> On Mon, Oct 23, 2023 at 3:26 PM Íñigo Huguet <ihuguet@redhat.com> wrote:
> >
> > On Mon, Oct 23, 2023 at 8:19 AM Vincent MAILHOL
> > <mailhol.vincent@wanadoo.fr> wrote:
> > >
> > > On Mon. 23 Oct. 2023 at 11:28, Jonathan Corbet <corbet@lwn.net> wrote:
> > > > Vincent MAILHOL <mailhol.vincent@wanadoo.fr> writes:
> > > >
> > > > > On Thu. 1 June 2023 at 16:53, Íñigo Huguet <ihuguet@redhat.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.
> > > > >>
> > > > >> 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@kdrag0n.dev>
> > > > >> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> > > > >> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
> > > > >> ---
> > > > >
> > > > > 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.
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
On Mon, Jun 03, 2024 at 09:18:53AM -0300, Jason Gunthorpe 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. What? No, vim is doing exactly what it is asked for here, it "trims all whitespace" when saving the file. I too just ran into this today, and it's a pain. This needs to be fixed, sorry. greg k-h
On Mon, Jun 3, 2024 at 2:18 PM Jason Gunthorpe <jgg@nvidia.com> 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>
On Mon, Jun 3, 2024 at 2:52 PM Mateusz Guzik <mjguzik@gmail.com> wrote: > > 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. This is https://github.com/editorconfig/editorconfig/issues/208 -- a `modified` value is proposed for just trimming modified lines. Given the latest version of the specification, it sounds to me like the intention is to trim all lines: "... to remove all whitespace characters ... in the file". Cheers, Miguel
On Mon, Jun 3, 2024 at 3:38 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > On Mon, Jun 3, 2024 at 2:52 PM Mateusz Guzik <mjguzik@gmail.com> wrote: > > > > 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. > > This is https://github.com/editorconfig/editorconfig/issues/208 -- a > `modified` value is proposed for just trimming modified lines. > > Given the latest version of the specification, it sounds to me like > the intention is to trim all lines: "... to remove all whitespace > characters ... in the file". > Looks like a dead report. I suggest someone whacks this file or at least moves it away from top of the repo (somewhere into Documentation maybe?) I did my civic duty. I'm disabling the file in my local neovim config, so the entire ordeal is no longer my problem. Cheers, -- Mateusz Guzik <mjguzik gmail.com>
On Sun, Jun 2, 2024 at 5:31 PM Mateusz Guzik <mjguzik@gmail.com> 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
On Sun, 2024-06-02 at 18:28 +0200, Miguel Ojeda wrote:
> On Sun, Jun 2, 2024 at 5:31 PM Mateusz Guzik <mjguzik@gmail.com> 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
Íñigo Huguet <ihuguet@redhat.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@kdrag0n.dev>
> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> Signed-off-by: Íñigo 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 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
On 09/06/2023 09:50, Jonathan Corbet wrote:
> Íñigo Huguet <ihuguet@redhat.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@kdrag0n.dev>
>> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
>> Signed-off-by: Íñigo 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 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.
On Fri, Jun 9, 2023 at 3:23 PM Mickaël Salaün <mic@digikod.net> wrote:
>
>
> On 09/06/2023 09:50, Jonathan Corbet wrote:
> > Íñigo Huguet <ihuguet@redhat.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@kdrag0n.dev>
> >> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> >> Signed-off-by: Íñigo 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 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
On Wed. 14 Jun. 2023 at 20:40, Íñigo Huguet <ihuguet@redhat.com> wrote:
> On Fri, Jun 9, 2023 at 3:23 PM Mickaël Salaün <mic@digikod.net> wrote:
> > On 09/06/2023 09:50, Jonathan Corbet wrote:
> > > Íñigo Huguet <ihuguet@redhat.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@kdrag0n.dev>
> > >> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> > >> Signed-off-by: Íñigo 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 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.
On Wed, Jun 14, 2023 at 2:55 PM Vincent MAILHOL
<mailhol.vincent@wanadoo.fr> wrote:
>
> On Wed. 14 Jun. 2023 at 20:40, Íñigo Huguet <ihuguet@redhat.com> wrote:
> > On Fri, Jun 9, 2023 at 3:23 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > On 09/06/2023 09:50, Jonathan Corbet wrote:
> > > > Íñigo Huguet <ihuguet@redhat.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@kdrag0n.dev>
> > > >> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> > > >> Signed-off-by: Íñigo 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 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
On Wed. 14 Jun. 2023 at 22:04, Íñigo Huguet <ihuguet@redhat.com> wrote: > On Wed, Jun 14, 2023 at 2:55 PM Vincent MAILHOL <mailhol.vincent@wanadoo.fr> wrote: > > On Wed. 14 Jun. 2023 at 20:40, Íñigo Huguet <ihuguet@redhat.com> 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.
On Thu, Jun 15, 2023 at 4:40 AM Vincent MAILHOL <mailhol.vincent@wanadoo.fr> wrote: > > On Wed. 14 Jun. 2023 at 22:04, Íñigo Huguet <ihuguet@redhat.com> wrote: > > On Wed, Jun 14, 2023 at 2:55 PM Vincent MAILHOL <mailhol.vincent@wanadoo.fr> wrote: > > > On Wed. 14 Jun. 2023 at 20:40, Íñigo Huguet <ihuguet@redhat.com> 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
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
On Fri, Jun 9, 2023 at 9:50 AM Jonathan Corbet <corbet@lwn.net> wrote:
>
> Íñigo Huguet <ihuguet@redhat.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@kdrag0n.dev>
> > Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> > Signed-off-by: Íñigo 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 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
On Fri, Jun 9, 2023 at 10:49 AM Íñigo Huguet <ihuguet@redhat.com> 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
On Fri, Jun 9, 2023 at 12:49 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > On Fri, Jun 9, 2023 at 10:49 AM Íñigo Huguet <ihuguet@redhat.com> 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
On Fri, Jun 9, 2023 at 10:49 AM Íñigo Huguet <ihuguet@redhat.com> wrote:
>
> On Fri, Jun 9, 2023 at 9:50 AM Jonathan Corbet <corbet@lwn.net> wrote:
> >
> > Íñigo Huguet <ihuguet@redhat.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@kdrag0n.dev>
> > > Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> > > Signed-off-by: Íñigo 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 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
On Fri, Jun 9, 2023 at 9:50 AM Jonathan Corbet <corbet@lwn.net> 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
Looks good to me, thanks!
Acked-by: Mickaël Salaün <mic@digikod.net>
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.
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.
On 01/06/2023 09:53, Íñigo Huguet 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 <danny@kdrag0n.dev>
> Signed-off-by: Danny Lin <danny@kdrag0n.dev>
> Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
> ---
> v2:
> - added special rule for patch files so it doesn't remove
> trailing whitespaces, making them unusable.
> v3:
> - moved all rules from [*] section to all the individual
> sections so they doesn't affect to unexpected files.
> - added some extensions and files from a patch from Danny
> Lin that didn't get to be merged:
> https://lore.kernel.org/lkml/20200703073143.423557-1-danny@kdrag0n.dev/
> However, the following file types hasn't been added
> because they don't have a clear common style:
> rst,pl,cocci,tc,bconf,svg,xsl,manual pages
> v4:
> - Analyzed with a script the styles used by different file types
> - Added rules for awd, dts, dtsi, dtso, s, S
> - Removed rules for rb and pm that has very few files in the tree
> - Removed rules for tools/perf/scripts/*/bin/*
> - Changed rules for py to better match the 2 styles that are present in
> the tree: 4 spaces by default and tabs for files in subdirectories
> tools/{perf,power,rcu,testing/kunit}
> ---
> .editorconfig | 32 ++++++++++++++++++++++++++
> .gitignore | 1 +
> Documentation/process/4.Coding.rst | 4 ++++
> Documentation/process/coding-style.rst | 4 ++++
> 4 files changed, 41 insertions(+)
> create mode 100644 .editorconfig
>
> diff --git a/.editorconfig b/.editorconfig
> new file mode 100644
> index 000000000000..854773350cc5
> --- /dev/null
> +++ b/.editorconfig
> @@ -0,0 +1,32 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +root = true
> +
> +[{*.{awk,c,dts,dtsi,dtso,h,mk,s,S},Kconfig,Makefile,Makefile.*}]
> +charset = utf-8
> +end_of_line = lf
> +trim_trailing_whitespace = true
> +insert_final_newline = true
> +indent_style = tab
> +indent_size = 8
> +
> +[*.{json,py,rs}]
> +charset = utf-8
> +end_of_line = lf
> +trim_trailing_whitespace = true
> +insert_final_newline = true
> +indent_style = space
> +indent_size = 4
> +
> +# this must be below the general *.py to overwrite it
> +[tools/{perf,power,rcu,testing/kunit}/**.py,]
> +indent_style = tab
> +indent_size = 8
> +
> +[*.yaml]
> +charset = utf-8
> +end_of_line = lf
> +trim_trailing_whitespace = unset
> +insert_final_newline = true
> +indent_style = space
> +indent_size = 2
> diff --git a/.gitignore b/.gitignore
> index 70ec6037fa7a..e4b3fe1d029b 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -100,6 +100,7 @@ modules.order
> #
> !.clang-format
> !.cocciconfig
> +!.editorconfig
> !.get_maintainer.ignore
> !.gitattributes
> !.gitignore
> diff --git a/Documentation/process/4.Coding.rst b/Documentation/process/4.Coding.rst
> index 1f0d81f44e14..c2046dec0c2f 100644
> --- a/Documentation/process/4.Coding.rst
> +++ b/Documentation/process/4.Coding.rst
> @@ -66,6 +66,10 @@ for aligning variables/macros, for reflowing text and other similar tasks.
> See the file :ref:`Documentation/process/clang-format.rst <clangformat>`
> for more details.
>
> +Some basic editor settings, such as indentation and line endings, will be
> +set automatically if you are using an editor that is compatible with
> +EditorConfig. See the official EditorConfig website for more information:
> +https://editorconfig.org/
>
> Abstraction layers
> ******************
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index 007e49ef6cec..ec96462fa8be 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -735,6 +735,10 @@ for aligning variables/macros, for reflowing text and other similar tasks.
> See the file :ref:`Documentation/process/clang-format.rst <clangformat>`
> for more details.
>
> +Some basic editor settings, such as indentation and line endings, will be
> +set automatically if you are using an editor that is compatible with
> +EditorConfig. See the official EditorConfig website for more information:
> +https://editorconfig.org/
>
> 10) Kconfig configuration files
> -------------------------------
On Fri, Jun 2, 2023 at 5:37 PM Mickaël Salaün <mic@digikod.net> wrote: > > Looks good to me, thanks! > > Acked-by: Mickaël Salaün <mic@digikod.net> > > 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
© 2016 - 2025 Red Hat, Inc.