This allows conveniently editing ebuilds and eclasses in editors which don't have a specific ebuild mode like Emacs and Vim do.

For example, kde-apps/kate with kde-frameworks/ktexteditor[editorconfig] can automatically read this file and adjust settings appropriately.

It's possible that going forward we may want to have pkgdev support custom
keys in this file for e.g. copyright year mangling too.

Signed-off-by: Sam James <sam@gentoo.org>
---
.editorconfig | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 .editorconfig

diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index 000000000000..94d5c584f580
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,8 @@
+root = true
+
+[*.{ebuild,eclass}]
+charset = utf-8
+end_of_line = lf
+insert_final_newline = true
+indent_style = tab
+trim_trailing_whitespace = true
--
2.40.0

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 24 Mar 2023, Sam James wrote:

I'm slightly confused. What repository is this intended for?

gentoo.git.

Then it looks wrong, conceptually. Or would it be o.k. if I committed ebuild-mode.el to the top-level directory of the Gentoo repository?

Seriously, these are generic settings which rather belong in the
user's configuration. For example, who would use anything else than
LF on Unix, or anything other than UTF-8 in 2023?

Ulrich

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmQdKwoPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4udTUH/AyujS+62JrdBBqXq5rfAaQjBithi1OBr7zr Apqed+KS1nv3UrGYjhFUPNmWnDLFKFCrwEKLVWnFK+q2jH7I0iYZgLgvnAoAkvaZ BwwopmkwNnN2IPjb3xopT7hAV9gIkJm73wocv8MXMdXFfYTIhOM/HY8OTWwZSa01 rU9zzh5z40u6QpKFkeEBok5P9BeY0KPts3HP8co1U6WX4QW6Mc82Q6JQJ3++yhab Yzos5tILGhAPH1KhlHd5ApRW0/l1tve8lDS/7uFTymnhtvvfNBUqQJE7PxHbcYIh CKSuDemjys3dK0tsbMpgpx/2I3nggDC6th5BhfrlP8yiu8S79cA=
=O9ii
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ulrich Mueller <ulm@gentoo.org> writes:

[[PGP Signed Part:Undecided]]

On Fri, 24 Mar 2023, Sam James wrote:

This allows conveniently editing ebuilds and eclasses in editors which don't >> have a specific ebuild mode like Emacs and Vim do.

I'm slightly confused. What repository is this intended for?

gentoo.git.

[[End of PGP Signed Part]]

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZB0owV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZC03gEAupicMnqOoS3Bt3L2yqrwuycYNci3RcWXbEXN 9c7hzGUBALWJci2r/gBx2w0FbLPQss0qFvuJ3MRi7dleBak+t1sD
=LU6O
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 24 Mar 2023, Sam James wrote:

This allows conveniently editing ebuilds and eclasses in editors which don't have a specific ebuild mode like Emacs and Vim do.

I'm slightly confused. What repository is this intended for?

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmQdJsMPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4ufP0H/18VbeVsBVdyIQiW8Bza76dqSIgusEc2BWOn n17m416vBufJShoIU+RapNhamQRKe6psevwxpzfLBh+mOnckiMP4F3LYpR4ZX6mA 9Bg8bYf4cB/L1zUCV2o0IUA/Rf9B1ePQg9K8+ahkIanA7c7zZpE8AjsE74iLFiGh 4SnK1lTAPpgRqaZLKgPPNUat/sduwGSIQiXbohmMyLJiv9y13KUZSVvthdHoD24L 8QGiHKzFSialhi0+LH2qFJHtAg0HCD2+T9jq6jqXS/5nmMtNuzZUKnBQ/F/+UMCh mN79HH4q4lAWqkRkDyxelN4+/KpUJFwixXmck0sbR5gL/Xvf1lg=
=rQ4t
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ulrich Mueller <ulm@gentoo.org> writes:

[[PGP Signed Part:Undecided]]

On Fri, 24 Mar 2023, Sam James wrote:

I'm slightly confused. What repository is this intended for?

gentoo.git.

Then it looks wrong, conceptually. Or would it be o.k. if I committed ebuild-mode.el to the top-level directory of the Gentoo repository?

The idea is to make other editors less-hostile when they don't have
a dedicated mode (like I said in the commit message). The specific
reason for doing this is because it's editor agnostic. So it's not
the same thing.

Seriously, these are generic settings which rather belong in the
user's configuration. For example, who would use anything else than
LF on Unix, or anything other than UTF-8 in 2023?

I mean, we can drop those bits and just put the tabs if you really want.

The indentation is really the most notable part and an annoyance if you
open an arbitrary editor to quickly change something.

Ulrich

[[End of PGP Signed Part]]

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZB0syF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZABsAEAkccxs3rxsd8wL+uQj9OVPcJeKryLYgwOEXIJ zHfcXXkA/RMsRkQaTzJ6VbzW8uGhCRGnVq4LYUQ9x0xqLRhD75wG
=EVav
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 24 Mar 2023, Sam James wrote:

The idea is to make other editors less-hostile when they don't have
a dedicated mode (like I said in the commit message). The specific
reason for doing this is because it's editor agnostic.

But is it? Emacs and Vim don't seem to natively support it. Nor does
any of the Micro-Emacsen (like mg or Zile). Does Nano, at least?

Ulrich

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmQdMAQPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4uyswIAMwbpjTmgFpCYL5zZfKfUS9up1JJokeCcIC7 /vNax4dOvuSEMJ3GWlLGloYKzWoENYULatSbU8eYyrEUEcTJzNjTyF+3QIg5K6yD 4+ZdryxG2diLavXO5UN3K3QrreVG433X+qn0/E2Ml+M6miXz6IeTKTw60WK9LUPw TiqXKsmTCyCtAgOV+LkvaD2K0Oveh7vWRuV/LtU2eAWbC+k+neAtWh0mgJL3ucWV /SwfMm/leuWRyjQcwBwtsTdKWs+hc0BKh1P0gBMMGETacKkfoc5u5kgq3S+ucMd5 MyI38LMGUt5qJQ271qDKoyc9T9FmXT++UgRy/Y7L/VdCV95gWvY=
=zVei
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 2023-03-24 at 02:14 +0000, Sam James wrote:

This allows conveniently editing ebuilds and eclasses in editors which don't have a specific ebuild mode like Emacs and Vim do.

For example, kde-apps/kate with kde-frameworks/ktexteditor[editorconfig] can automatically read this file and adjust settings appropriately.

It's possible that going forward we may want to have pkgdev support custom keys in this file for e.g. copyright year mangling too.

I think following standards is good, so +1 from me.

Could you perhaps add a comment with the URL to the specification
on top?

--
Best regards,
Michał Górny

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ulrich Mueller <ulm@gentoo.org> writes:

[[PGP Signed Part:Undecided]]

On Fri, 24 Mar 2023, Sam James wrote:

The idea is to make other editors less-hostile when they don't have
a dedicated mode (like I said in the commit message). The specific
reason for doing this is because it's editor agnostic.

But is it? Emacs and Vim don't seem to natively support it. Nor does
any of the Micro-Emacsen (like mg or Zile). Does Nano, at least?

Yes, being editor agnostic doesn't mean it has to be universally
supported by every editor.

I don't think needing a plugin is really an issue either (although
not all editors need one for it), given someone could easily have it
installed in general, and then want to start contributing.

Our own vapier ended up requesting it at https://savannah.gnu.org/bugs/?61947 for nano, although it hasn't been implemented yet (and may not be).

Ulrich

[[End of PGP Signed Part]]

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZB0zhF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZCTfAEA1WWgcAb6wAm4LrlJkLOyoXG/ryVRWPSgrbR/ dyC6hfoA/1BsbYtqZY5ONB6M4d+vNRam7flO2A7sHUXOs5lP+QIL
=SRST
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24/03/2023 05.46, Ulrich Mueller wrote:

On Fri, 24 Mar 2023, Sam James wrote:

I'm slightly confused. What repository is this intended for?

gentoo.git.

Then it looks wrong, conceptually. Or would it be o.k. if I committed ebuild-mode.el to the top-level directory of the Gentoo repository?

I do not think the comparison with ebuild-mode.el is sound:
ebuild-mode.el appears imperative, while .editorconfig is declarative. Furthermore, and more importantly, ebulid-mode.el is (more or less) editor-specific, while .editorconfig is editor agnostic.

That said, given how coupled ebuild-mode is with gentoo.git, I
personally would not mind if it where managed in the same repository.
(with ebuild-mode not being shipped to the users as part of "emerge
--sync"). One could imagine that if a major ebuild style change is
rolled out, it is done in a single commit that affects all ebuilds and ebuild-mode.

In any case, I am a fan of .editorconfig. Hence +1 from me for adding it
to gentoo.git.

- Flow

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 24 Mar 2023, Florian Schmaus wrote:

Then it looks wrong, conceptually. Or would it be o.k. if I committed
ebuild-mode.el to the top-level directory of the Gentoo repository?

I do not think the comparison with ebuild-mode.el is sound:
ebuild-mode.el appears imperative, while .editorconfig is declarative. Furthermore, and more importantly, ebulid-mode.el is (more or less) editor-specific, while .editorconfig is editor agnostic.

Sorry, a better example for Emacs would have been .dir-locals.el in
the top-level directory.

That said, given how coupled ebuild-mode is with gentoo.git, I
personally would not mind if it where managed in the same repository.
[...]

That's not going to happen, because it simply doesn't belong there
(and neither does any other editor configuration IMHO).

In any case, I am a fan of .editorconfig. Hence +1 from me for adding
it to gentoo.git.

But what does it do, effectively? Apart from the common-sense settings
(utf-8, no trailing whitespace, etc.) which should be the default for
every editor, the only setting specific to ebuilds is to enable tabs.
Then again, it doesn't even say that they represent 4 spaces.

Ulrich

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmQdXK0PHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4uKcMH/RzWgcKplmA2j92aeBkOE2aI6f4WltO09QEl SGX6G+LpDrhAOtBNWwfMiKvsn1Nxkjn5iwAhcN9jCNTF9KBSVYZuL4AOHYv8R5Hs EIRmF3Fkxwca4SLH8QJ825s97Mx20T+7yR5M/OXwgh8uUHYUu6XyzYLB+Apodk9g 8fmlN1qLyFtdk3v7ymoLcGMKJjLaw9vuZ6MunJDDxgSlldDxJ9SdsqQ48/zGt8G9 rp6X6CbbFD/RrFWYznYY8ZOkWFjAsx4l83Zg9fQI42zsvCZXKxrnRB1eUXriq07p dOUo18SR7YjU63T/6qzYjt0C/k15aeh7n1cgSAwsdPEDkR9K240=
=YVop
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ulrich Mueller <ulm@gentoo.org> writes:

[[PGP Signed Part:Undecided]]

On Fri, 24 Mar 2023, Florian Schmaus wrote:

Then it looks wrong, conceptually. Or would it be o.k. if I committed
ebuild-mode.el to the top-level directory of the Gentoo repository?

I do not think the comparison with ebuild-mode.el is sound:
ebuild-mode.el appears imperative, while .editorconfig is declarative.
Furthermore, and more importantly, ebulid-mode.el is (more or less)
editor-specific, while .editorconfig is editor agnostic.

Sorry, a better example for Emacs would have been .dir-locals.el in
the top-level directory.

Projects can and do include mode lines and .dir-locals.el.

That said, given how coupled ebuild-mode is with gentoo.git, I
personally would not mind if it where managed in the same repository.
[...]

That's not going to happen, because it simply doesn't belong there
(and neither does any other editor configuration IMHO).

This comes across as arguing for the sake of it if you disagree on
principle. Do you have constructive feedback about the actual contents
of it? Would you like to know more about the available options?

In any case, I am a fan of .editorconfig. Hence +1 from me for adding
it to gentoo.git.

But what does it do, effectively? Apart from the common-sense settings (utf-8, no trailing whitespace, etc.) which should be the default for
every editor, the only setting specific to ebuilds is to enable tabs.
Then again, it doesn't even say that they represent 4 spaces.

That's just because I forgot to put that bit in. Also, these aren't
default for every editor, even if you wish that were the case.

Ulrich

[[End of PGP Signed Part]]

-----BEGIN PGP SIGNATURE-----

iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZB1nt18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZBtIQEA9Ib6xaGso6ExhkCq9eQC2eH96EedU+Yj+HIT 1Zk87LMA/A/2j1Sm/WR8KsfigF43gHaWwCuH1BZkYb1QdEwJUFwJ
=G+rD
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Am Freitag, dem 24.03.2023 um 09:17 +0100 schrieb Ulrich Mueller:

But what does it do, effectively? Apart from the common-sense
settings (utf-8, no trailing whitespace, etc.) which should be the
default for every editor,

*should*. And just because it's the default doesn't mean a user can't
configure such settings to something else locally for some reason and
then forget that we use UTF-8 and no trailing whitespaces in
gentoo.git.

the only setting specific to ebuilds is to enable tabs.

Which I'd consider important, since I get the feeling that many people
seem to prefer spaces over tabs and might have their editor configured
that way.

Then again, it doesn't even say that they represent 4 spaces.

Is that really important? I don't think we should force a tab width
for the user if we don't have a good reason to do so. The good thing
about tabs is that the user can set the tab width to their liking. If
we enforce a tab width, that would essentially undermine that one big
advantage over spaces.

Adrian

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQcg0lBH7AUcc2KLs8BUfPlCnnJ+QUCZB2FZwAKCRABUfPlCnnJ +RFmAQDz6cSWFAotAW0fzGDOIyMpTsSoW1/2AB0ZrRSeWKKnSAD/U+cSF3ieyInm F8+y8DLwiQFz1cjc/gbpsW/V7slcAQU=
=r6qm
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 24 Mar 2023, Adrian Schollmeyer wrote:

Then again, it doesn't even say that they represent 4 spaces.

Is that really important? I don't think we should force a tab width
for the user if we don't have a good reason to do so. The good thing
about tabs is that the user can set the tab width to their liking. If
we enforce a tab width, that would essentially undermine that one big advantage over spaces.

We don't force anything, and users can configure whatever tab width
they want. This is a about having a reasonable *default* value for
ebuilds. Traditionally our TABs are four positions wide (which also
plays a role when it comes to other style guidelines like "try to keep
lines no wider than 80 positions").

Besides, ebuild-mode has used a default tab-width of 4 since 2006, and
I haven't heard a single complaint about it.

Ulrich

-----BEGIN PGP SIGNATURE-----

iQFDBAEBCAAtFiEEtDnZ1O9xIP68rzDbUYgzUIhBXi4FAmQdj6YPHHVsbUBnZW50 b28ub3JnAAoJEFGIM1CIQV4u1CkIANhY/dyEf9Ajpbmf0yvlrtAziKdNqrgZWYcu t/DJMnX7jt3OYzPGFaYCesXjLiruXsPuLsyzL35yeq0pyvbDUB5sp3TpT/SXXW7V +YGzbaXfzT4sAx/FOWdI8wKOJD1hBy4MuN1th8OaSuC5fX/DZmeO05O8n/rtqeVD llSMCz3DTCJax6WhB1HaFn2u9dgAPeIdT+gJubMrGWf5jVOz1AQvJrdiSpzwSqWa lU/Mbn5NAdjD8GwTm4oXyiH4RMgTNbP0nuey970HceOktCxuUl3n03m7aqSckvxM 3MmDbmFfFw+6BSoAZ3/bDl6Dfl7g9tHVAoVMQQoBqtPaW94/eWs=
=qYp5
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)