EditorConfig is a standard for defining basic editor configuration in
projects. There is support available for 47 code editors as of writing,
including both built-in and extension support. Many notable projects
have adopted the standard already, including zsh, htop, and qemu.
While this isn't a full-fledged C code style specifier, it does set some
basic ground rules that make it more convenient for contributors to use
any editor of their choice and not have to worry about indentation, line
endings, encoding, final newlines, etc. This should make it
significantly easier to conform to the kernel's general code style when
used in combination with clang-format.
For more information, check the official EditorConfig website:
https://editorconfig.org/
Signed-off-by: Danny Lin <[email protected]>
---
.editorconfig | 16 ++++++++++++++++
.gitignore | 1 +
Documentation/process/4.Coding.rst | 6 ++++++
3 files changed, 23 insertions(+)
create mode 100644 .editorconfig
diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index 000000000000..580d2e90d855
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0
+# Linux kernel EditorConfig file (https://editorconfig.org/)
+
+# Located at the project root
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+insert_final_newline = true
+
+indent_style = tab
+indent_size = 8
+
+# This avoids introducing too many unnecessary changes in trivial commits
+trim_trailing_whitespace = false
diff --git a/.gitignore b/.gitignore
index 87b9dd8a163b..956bcc3c9d76 100644
--- a/.gitignore
+++ b/.gitignore
@@ -89,6 +89,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 13dd893c9f88..c5c46bcafdad 100644
--- a/Documentation/process/4.Coding.rst
+++ b/Documentation/process/4.Coding.rst
@@ -66,6 +66,12 @@ 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
******************
--
2.27.0
Hi Danny,
On Fri, Jul 3, 2020 at 2:16 AM Danny Lin <[email protected]> wrote:
>
> +[*]
> +charset = utf-8
> +end_of_line = lf
While UTF-8 and LF are probably OK for all files, I am not 100% sure about:
> +insert_final_newline = true
> +indent_style = tab
> +indent_size = 8
for other languages and non-code files we may have around. Perhaps it
is best to avoid `[*]` unless we are sure?
Cheers,
Miguel
On Thursday, July 2, 2020 at 10:38 PM, Miguel Ojeda wrote:
> Hi Danny,
>
> On Fri, Jul 3, 2020 at 2:16 AM Danny Lin <[email protected]> wrote:
> > +[*]
> > +charset = utf-8
> > +end_of_line = lf
>
> While UTF-8 and LF are probably OK for all files, I am not 100% sure
about:
> > +insert_final_newline = true
> > +indent_style = tab
> > +indent_size = 8
>
> for other languages and non-code files we may have around. Perhaps it
> is best to avoid `[*]` unless we are sure?
Most of the other exceptions can be accomodated for with more specific
rules below the base [*] section. I just went through most of the
kernel's files and added rules for the vast majority of the exceptinos
to the 8-column tab indent style, though there are still some that
haven't been covered.
It looks like some types of files lack consistent indentation, e.g.
arch/mips/*/Platform and some shell scripts in scripts/ tools/testing/
selftests/ftrace/test.d/kprobe/*.tc. There are also some files that were
highly inconsistent even within themselves (e.g. drivers/gpu/drm/amd/
amdkfd/cwsr_trap_handler_gfx*.asm), so setting indentation settings to
something sane by default doesn't make them any worse. After all, no
automated code style tooling is perfect and there will be edge cases
where it breaks down.
That being said, I think most of the exceptions should be taken care of
now; please feel free to suggest a better way to deal with these.
>
> Cheers,
> Miguel
On Fri, Jul 3, 2020 at 9:31 AM Danny Lin <[email protected]> wrote:
>
> Most of the other exceptions can be accomodated for with more specific
> rules below the base [*] section. I just went through most of the
> kernel's files and added rules for the vast majority of the exceptinos
> to the 8-column tab indent style, though there are still some that
> haven't been covered.
Very good! That looks much better.
Are there too many file types that use tabs? If not, then I think it
is best to add a section for "General tab" files like for the others,
in order to be explicit and to have the list around.
> It looks like some types of files lack consistent indentation, e.g.
> arch/mips/*/Platform and some shell scripts in scripts/ tools/testing/
> selftests/ftrace/test.d/kprobe/*.tc. There are also some files that were
> highly inconsistent even within themselves (e.g. drivers/gpu/drm/amd/
> amdkfd/cwsr_trap_handler_gfx*.asm), so setting indentation settings to
> something sane by default doesn't make them any worse. After all, no
> automated code style tooling is perfect and there will be edge cases
> where it breaks down.
Yeah, do not worry about inconsistencies. For `.clang-format`, I
picked the options based on 1) whether there was an official code
style guideline and 2) if not, the one that minimizes the number of
changes, i.e. the most popular one across files.
Cheers,
Miguel