On 22.07.2016 17:09, Emil Velikov wrote:
On 18 July 2016 at 00:46, Eric Engestrom <e...@engestrom.ch> wrote:
A few weeks ago, Jose Fonseca suggested [0] we use .editorconfig files
to try and enforce the formatting of the code, to which Michel Dänzer
suggested [1] we start by importing the existing .dir-locals.el
settings.
This is a first draft, with settings from the mentioned emacs files,
augmented with what I could see was the current practice in various
submodules.
Note that it might not reflects the desired formatting. Please say so if
this is the case. I expect several of these .editorconfig files are in
this situation, so don't hesitate to just tell me "the current formatting
for X is wrong, we want to eventually match the project-wide formatting,
so don't create this .editorconfig".
From a quick skim all I believe all of those are fine. We might need
tab_width in the odd place (r600/radeonsi/fdno/haiku), but those are
to be added by people who know the correct value.
The Radeon ones use a tab width of 8. I assume that's just the default
value.
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,40 @@
+# To use this config on you editor, follow the instructions on:
+# http://editorconfig.org
+
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
Agree with Jose on this one. While we don't have any \n\r instances
in-tree, this will cause some annoying churn for out-of-tree code
which depend on \n\r.
+[{Makefile*,*.mk}]
+indent_style = tab
+
+[*.py,SCons*]
Do we want to use {} here, just like the Makefile(s) a couple of lines above ?
Side note: we have a few python scripts which don't end with .py that
we might(?) want to rename.
+[*.{dsp,dsw,sln,vcproj}]
We don't have any such files in-tree. Considering the above comment
can we drop this ?
--- /dev/null
+++ b/src/mesa/drivers/dri/radeon/.editorconfig
@@ -0,0 +1,3 @@
+# Coin toss? Leaving this one empty (ie. global rules) for now because
+# there are files with 3-spaces, 4-spaces and tab indentations.
+# Tell me what you'd prefer if not the 3-space style of the rest of Mesa.
IMHO having something is always better than none. So fwiw I'd just
keep this file.
Fine with me.
Cheers,
Nicolai
Thanks for going through and adding all of these :-)
-Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
