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