It's a pain when you come back to a code base you haven't touched in a
while and realise whatever indent settings you were using having
carried over. Add an editorconfig and be done with it.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

---
v2
  - drop mention of custom major modes (not needed here)
  - include section for assembly
---
 .editorconfig | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)
 create mode 100644 .editorconfig

diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index 0000000..c72a55c
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,29 @@
+# EditorConfig is a file format and collection of text editor plugins
+# for maintaining consistent coding styles between different editors
+# and IDEs. Most popular editors support this either natively or via
+# plugin.
+#
+# Check https://editorconfig.org for details.
+#
+
+root = true
+
+[*]
+end_of_line = lf
+insert_final_newline = true
+charset = utf-8
+
+[Makefile*]
+indent_style = tab
+indent_size = 8
+emacs_mode = makefile
+
+[*.{c,h}]
+indent_style = space
+indent_size = 4
+emacs_mode = c
+
+[*.{s,S}]
+indent_style = tab
+indent_size = 8
+emacs_mode = asm
-- 
2.39.2

On 5/30/2024 6:23 AM, Alex Bennée wrote:
> It's a pain when you come back to a code base you haven't touched in a
> while and realise whatever indent settings you were using having
> carried over. Add an editorconfig and be done with it.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>


Adding an editorconfig seems like a great idea IMO.  But I wonder - will 
it result in unintentional additional changes when saving a file that 
contains baseline non-conformance?

Related: would a .clang-format file also be useful? git-clang-format can 
be used to apply formatting changes only on the code that's been changed.

Also: should we consider excluding any exceptional files that we don't 
expect to conform?


> ---
> v2
>    - drop mention of custom major modes (not needed here)
>    - include section for assembly
> ---
>   .editorconfig | 29 +++++++++++++++++++++++++++++
>   1 file changed, 29 insertions(+)
>   create mode 100644 .editorconfig
>
> diff --git a/.editorconfig b/.editorconfig
> new file mode 100644
> index 0000000..c72a55c
> --- /dev/null
> +++ b/.editorconfig
> @@ -0,0 +1,29 @@
> +# EditorConfig is a file format and collection of text editor plugins
> +# for maintaining consistent coding styles between different editors
> +# and IDEs. Most popular editors support this either natively or via
> +# plugin.
> +#
> +# Check https://editorconfig.org for details.
> +#
> +
> +root = true
> +
> +[*]
> +end_of_line = lf
> +insert_final_newline = true
> +charset = utf-8
> +
> +[Makefile*]
> +indent_style = tab
> +indent_size = 8
> +emacs_mode = makefile
> +
> +[*.{c,h}]
> +indent_style = space
> +indent_size = 4
> +emacs_mode = c
> +
> +[*.{s,S}]
> +indent_style = tab
> +indent_size = 8
> +emacs_mode = asm

Brian Cain <quic_bcain@quicinc.com> writes:

> On 5/30/2024 6:23 AM, Alex Bennée wrote:
>> It's a pain when you come back to a code base you haven't touched in a
>> while and realise whatever indent settings you were using having
>> carried over. Add an editorconfig and be done with it.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>
>
> Adding an editorconfig seems like a great idea IMO.  But I wonder -
> will it result in unintentional additional changes when saving a file
> that contains baseline non-conformance?

This is for the semihosting tests, we have had an editorconfig in the
mainline QEMU repo for a long time. Generally it's just standardising
what people usually hand configure their editors for which can range in
their aggressiveness in reformatting existing code.

> Related: would a .clang-format file also be useful? git-clang-format
> can be used to apply formatting changes only on the code that's been
> changed.

As a pre-commit hook? Or via something like clangd? 

> Also: should we consider excluding any exceptional files that we don't
> expect to conform?

Do we have such files? We certainly have a bunch of legacy whitespace
damage hanging about but I didn't think we had a lot of non-conforming
files.

<snip>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

On Fri, 31 May 2024 at 09:54, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> Brian Cain <quic_bcain@quicinc.com> writes:
> > Related: would a .clang-format file also be useful? git-clang-format
> > can be used to apply formatting changes only on the code that's been
> > changed.
>
> As a pre-commit hook? Or via something like clangd?

I think last time somebody looked at clangd it wasn't quite
flexible enough to format code to QEMU's style preferences.
But that was some years ago, so I might be misremembering or
the situation might have changed.

In terms of project consensus, I think "here's tooling/config
you can use to follow our formatting preferences if you like"
is probably a better place to start than anything that is
an automatically-applied-by-default check.

(For the semihosting-tests I wouldn't bother, because they
get almost no contributions: 8 commits in the last 5 years.)

thanks
-- PMM