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
Signed-off-by: Íñigo Huguet <[email protected]>
---
v2: added special rule for patch files so it doesn't remove
trailing whitespaces, making them unusable.
---
.editorconfig | 22 ++++++++++++++++++++++
.gitignore | 1 +
2 files changed, 23 insertions(+)
create mode 100644 .editorconfig
diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index 000000000000..082d81bd0475
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,22 @@
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.{c,h}]
+indent_style = tab
+indent_size = 8
+
+[{Makefile,Makefile.*,*.mk}]
+indent_style = tab
+indent_size = 8
+
+[*.{py,rs}]
+indent_style = space
+indent_size = 4
+
+[*.{patch,diff}]
+trim_trailing_whitespace = false
diff --git a/.gitignore b/.gitignore
index 70ec6037fa7a..c68f8f247379 100644
--- a/.gitignore
+++ b/.gitignore
@@ -105,6 +105,7 @@ modules.order
!.gitignore
!.mailmap
!.rustfmt.toml
+!.editorconfig
#
# Generated include files
--
2.39.2
Hi Íñigo,
On Tue, Apr 4, 2023 at 9:55 AM Íñ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.
Please see https://lore.kernel.org/lkml/[email protected]/
for a previous patch & discussion, as well as commit fa60ce2cb450
("treewide: remove editor modelines and cruft") for a related cleanup.
Cc'ing those that gave some feedback back then.
Danny's v2 patch has some extra extensions/languages it manages as
well as some docs, and yours handles things that one doesn't, like the
Rust files and `Makefile.*` cases. So it would be nice to get a
version that merges everything from both of you, likely as
co-developers.
It still remains important to see if somebody's workflow could break
due to this, especially for the catch-all section `[*]` and for
options like `trim_trailing_whitespace` which can actually break
things like patch files as you note in the changelog. Perhaps landing
it in linux-next for an extended period of time (e.g. a few kernel
cycles) is one way to find out, or we could start without the
"dangerous" options. What do others think?
By the way, for the next/merged version, in your side please keep
`!.editorconfig` sorted and in the other side please avoid the
duplicated `.tc` case (which I just noticed).
Cheers,
Miguel
On Tue, Apr 4, 2023 at 11:51 AM Miguel Ojeda
<[email protected]> wrote:
>
> Hi Íñigo,
>
> On Tue, Apr 4, 2023 at 9:55 AM Íñ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.
>
> Please see https://lore.kernel.org/lkml/[email protected]/
> for a previous patch & discussion, as well as commit fa60ce2cb450
> ("treewide: remove editor modelines and cruft") for a related cleanup.
> Cc'ing those that gave some feedback back then.
>
> Danny's v2 patch has some extra extensions/languages it manages as
> well as some docs, and yours handles things that one doesn't, like the
> Rust files and `Makefile.*` cases. So it would be nice to get a
> version that merges everything from both of you, likely as
> co-developers.
I will be happy to prepare the patch, as co-developers, if Danny agrees.
> It still remains important to see if somebody's workflow could break
> due to this, especially for the catch-all section `[*]` and for
> options like `trim_trailing_whitespace` which can actually break
> things like patch files as you note in the changelog. Perhaps landing
> it in linux-next for an extended period of time (e.g. a few kernel
> cycles) is one way to find out, or we could start without the
> "dangerous" options. What do others think?
I can move everything from [*] to the extension based sections
(*.{c,h} and so on), so it is safer. It can only happen that someone
notices that a weird file is not auto-formatted, and hopefully gives
feedback to add it to .editorconfig.
About the potential break of some workflows, and after reading the
previous conversation, I don't think there is much else we can do. In
any case, it won't be that harmful: using editorconfig is almost
always opt-in, and if anyone has a problem, he will disable
editorconfig to complete the changes and hopefully give feedback.
If you think that it's better to keep it in linux-next for some time,
it's fine, but I don't think it's necessary. As I say, I don't think
it can be that much disturbing.
Finally, about the files without extension but with a shebang,
mentioned by Masahiro, it seems that they're seriously considering
supporting tags based on language, like [[python]] and [[bash]], but
nothing has been done yet, so, again, there's no much we can do. If
someone frequently update specific files and want editorconfig
formatting for them, their full paths can be added.
Regards
> By the way, for the next/merged version, in your side please keep
> `!.editorconfig` sorted and in the other side please avoid the
> duplicated `.tc` case (which I just noticed).
>
> Cheers,
> Miguel
>
--
Íñigo Huguet
On Tue, Apr 04, 2023 at 4:37 AM, Íñigo Huguet wrote:
> On Tue, Apr 4, 2023 at 11:51 AM Miguel Ojeda
> <[email protected]> wrote:
>>
>> Hi Íñigo,
>>
>> On Tue, Apr 4, 2023 at 9:55 AM Íñ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.
>>
>> Please see https://lore.kernel.org/lkml/[email protected]/
>> for a previous patch & discussion, as well as commit fa60ce2cb450
>> ("treewide: remove editor modelines and cruft") for a related cleanup.
>> Cc'ing those that gave some feedback back then.
>>
>> Danny's v2 patch has some extra extensions/languages it manages as
>> well as some docs, and yours handles things that one doesn't, like the
>> Rust files and `Makefile.*` cases. So it would be nice to get a
>> version that merges everything from both of you, likely as
>> co-developers.
>
> I will be happy to prepare the patch, as co-developers, if Danny agrees.
That's fine by me. Thanks for picking this back up!
>
>> It still remains important to see if somebody's workflow could break
>> due to this, especially for the catch-all section `[*]` and for
>> options like `trim_trailing_whitespace` which can actually break
>> things like patch files as you note in the changelog. Perhaps landing
>> it in linux-next for an extended period of time (e.g. a few kernel
>> cycles) is one way to find out, or we could start without the
>> "dangerous" options. What do others think?
>
> I can move everything from [*] to the extension based sections
> (*.{c,h} and so on), so it is safer. It can only happen that someone
> notices that a weird file is not auto-formatted, and hopefully gives
> feedback to add it to .editorconfig.
>
> About the potential break of some workflows, and after reading the
> previous conversation, I don't think there is much else we can do. In
> any case, it won't be that harmful: using editorconfig is almost
> always opt-in, and if anyone has a problem, he will disable
> editorconfig to complete the changes and hopefully give feedback.
>
> If you think that it's better to keep it in linux-next for some time,
> it's fine, but I don't think it's necessary. As I say, I don't think
> it can be that much disturbing.
>
> Finally, about the files without extension but with a shebang,
> mentioned by Masahiro, it seems that they're seriously considering
> supporting tags based on language, like [[python]] and [[bash]], but
> nothing has been done yet, so, again, there's no much we can do. If
> someone frequently update specific files and want editorconfig
> formatting for them, their full paths can be added.
>
> Regards
>
>> By the way, for the next/merged version, in your side please keep
>> `!.editorconfig` sorted and in the other side please avoid the
>> duplicated `.tc` case (which I just noticed).
>>
>> Cheers,
>> Miguel
>>
>
>
> --
> Íñigo Huguet
Best,
Danny