From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Bj=C3=B6rn?= Bidar Newsgroups: gmane.emacs.devel Subject: Re: Adding git-commit highlight mode? Date: Sun, 05 Jan 2025 02:32:58 +0200 Message-ID: <18769.7368369967$1736037249@news.gmane.org> References: <37733be4476e1c2b6e873c967c79cb0035959a9e.camel@yandex.ru> <083310b3-a288-5c75-c835-84595e134682@gmail.com> <56c9eadd95367cd3fd7c8414dc3e86b243a4b3d7.camel@yandex.ru> <87sepyeo9t.fsf@bernoul.li> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32013"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Konstantin Kharlamov , Jim Porter , emacs-devel@gnu.org To: Jonas Bernoulli Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 05 01:34:01 2025 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tUEae-00089s-R4 for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Jan 2025 01:34:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUEZn-0000vF-2i; Sat, 04 Jan 2025 19:33:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUEZk-0000uq-RV for emacs-devel@gnu.org; Sat, 04 Jan 2025 19:33:04 -0500 Original-Received: from thaodan.de ([185.216.177.71]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUEZh-0007mI-F6 for emacs-devel@gnu.org; Sat, 04 Jan 2025 19:33:04 -0500 Original-Received: from odin (dsl-trebng12-50dc7b-49.dhcp.inet.fi [80.220.123.49]) by thaodan.de (Postfix) with ESMTPSA id 33866D0002E; Sun, 5 Jan 2025 02:32:59 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail; t=1736037179; bh=BHptBG/KSmbrNvogLOg435CuJpgq2sJ/0pIY2KqDYuE=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=YBamwzPvw6ah3vMZlO9Ka8FlzsxMWPfNutlV6loNH+DTHLXQ94x4ztcJ0Lum8E9bi 6xhqh8fZIuSNVMjCdnclo5fZi1q6Ehg/KYLf8yNCPKwrthtRd8rBablLxaxrfZe1AT Gon0jeVzeVYeTfYLBEei1x45y9Wp8R7cvSpiJW4+2Hy3UpTJhisVH0zIEohooqpoKT YGnLW4J2PXLd+wDxURZHOBDhEH2f6nneOf8DXpJddKJxHFM7fvcBGPuXUf8UlhZ9nm T10Zq1RinVbeNtS0FJ++uZCfy8R5RUGXKv8Rz7U9H9SAn42Sw+4TJrbsITsjnhp/Uk vi04NfnQ9qfmGNKE3YBUVcyOQAngMMaj/aB8Qf970SUptyhWrHF/+4Flfh9Wq7rBp5 9f21Wh7Z0c5qRZVut9V62QlvQk4vNUJfig+Eo+t4+0iz4ZY/QFL3mryswyMcZ/m2oz Hg9Kx6/KXGrn8LF9c9Kerz9ZKe/kgh1PM8I3OyHGMVe8Bu+AYHYpB+XTyOmAF1tLB1 yGwsXEKKJkjE+XPvt8j7kM3vDTUDPxgzN030C0QRINny9xDB9VSQZlEpH4vyN9TN4I g0MKTWWNvT2g3JER/Fv10aerwgwkuODx7uPOIN6XHXcLqnWS9P8I8MOuvTCXIPvu2X 47VpMXtReQ7Xp2xNnTdYVl1Y= In-Reply-To: <87sepyeo9t.fsf@bernoul.li> (Jonas Bernoulli's message of "Sat, 04 Jan 2025 13:50:38 +0100") Autocrypt: addr=bjorn.bidar@thaodan.de; prefer-encrypt=nopreference; keydata= mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlH Received-SPF: pass client-ip=185.216.177.71; envelope-from=bjorn.bidar@thaodan.de; helo=thaodan.de X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, INVALID_MSGID=0.568, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327695 Archived-At: Jonas Bernoulli writes: >>> Using Jim's mode comes as close as it gets to not reinventing the >>> wheel. As mentioned by Stefan elsewhere in the thread, Jonas' git- >>> commit that is part of magit can't be easily included for license >>> reasons. >> >> Most of the code was written by Jonas. If either the other authors code >> is replaced or they have also assigned their copyright to the FSF it >> could be included. > > In principal, I am not opposed to adding git-commit.el, or parts > thereof, to Emacs, but there are some road blocks. > > A. The part you appear to be most interested in (going by the > "highlight" in the subject), derives from code written by a person > who had a very low opinion of the FSF when they quit the community. > I doubt they would we willing to assign their copyright to the FSF. Previously I thought much of that code had been rewritten by you since only the initial few commits contained other contributors with bigger changes. But nonetheless no we have life with the NIH in this context. > B. The part that makes the whole thing work for Magit depends on > with-editor.el and adding that to Emacs failed previously because > the Emacs maintainer wanted to change it significantly and I am not > willing to put in that work (it works for me and I have other more > impactful work lined up). I know of the discussion. It's sad to your that the requested changes ended in only talk no work from their side. Maybe adding something aand then doing adjustments would work better. > It might be a good idea to summarize the functionality available in > git-commit.el, especially because some people are avoiding to look at > it, so they don't spoil their ability to re-implement it from scratch. > > Those who don't intend to work on a re-implementation, might want to > look at > git show d35266e580cc80ee5791d928bfcb22268ee51b97:git-commit-mode.el > > That's the code you likely won't get a copyright assignment for. > It contains the following features: > > 1. Font-locking, including for "violations of the conventions" like > non-empty second line and overly long lines. > > 2. Support for inserting "Git trailers" (here still called > "pseudo-headers"). E.g., "Signed-off-by: Name " > > 3. Support for nagging the user about violations of the conventions > when trying to finish the commit. > > Someone who does not intend to get involved in the potential > re-implementation of those parts but is familiar with what this project > does and does not consider derived code, should really look at this and > compare it to the current git-commit.el. IMO not much remains and what > remains has in large parts been re-implemented already. Maybe all we > would have to do are some clean-room implementations of a few font-lock > keyword entries. > I wonder how much of these can be considered derived if the code is originally derived from Emacs code or manual examples. > Beyond significant improvements/re-implementations of the above > features, current git-commit.el offers the following features: > > 4. Options to control whether certain optional functionality, such as > flyspell, is turned on. > > 5. Support for cycling through past messages. This is based on similar > functionality in log-edit.el. It might be best to just port the > improvements to that built-in library. That sounds like a good idea. It is a feature which can safe very much time e.g. in case something goes wrong or to reuse commit messages. > 6. Allow for an arbitrary major-mode to be used. git-commit-mode is > just minor-mode which enables additional font-locking, adds to some > hooks, and adds some key bindings. However we briefly pretend that > git-commit-mode is a major-mode, so that .dir-locals[-2].el settings > can be taken into account. This one big feature which makes git-commit-mode so adjustable so that depending on the repository contributed it can be adjusted to e.g. use markdown mode or Dick's magit-patch-changelog mode to better deal with the GNU changelog requirements. > 7. Setup commands for finishing and aborting the commit process in > co-operation with magit and with-editor. I assume that's something that VC could hook into. > 8. Support for path mangling necessary when users insist on using cygwin > Emacs with windows-nt Git builds, or vice-versa. Magit also contains > such path fixing code. It might be a good idea if instead Emacs > itself provided such kludges. That's something file name handlers can deal with if I understood correctly. > 9. Support for changing the default-directory from inside the Git > directory to the working directory, which is necessary because of > security features in newer Git versions, which in some cases prevent > running git inside the Git directory. This depends on Magit. > > I have some concerns, contemplating the addition of git-commit.el to > Emacs, most importantly > > - I imagine that one likely way of doing it is to ripping out the Magit- > and With-Editor specific bits, and instead adding hooks and such, to > allow Magit to bring them back. Maybe that would work well for > me/Magit, put it could also turn out to be very painful. It would > certainly complicate the code. > > - Many users are going to stick to Emacs releases that don't have a > bundled git-commit.el for many years to come (beyond the end of the > decade, I am afraid). It will become increasingly hard for me to > continue to support Emacs releases from before the addition. Is there a better way to make Emacs more modular akin to XEmacs? Then updating individual modules might be possible. In any case similar to Eglot such new additions could be available through Elpa or if the module be developed outside of Emacs with synchronisations to Emacs then from the outside module. Using ELPA has the downside that you have to use package.el thou. > - I would welcome handing of responsibility for this to someone else, > but at the same time I fear that doing so would actually result in > more, not less, work for me. git-commit.el is pretty much "finished". > Adjusting it to comply with emacs-devel's expectations will be a lot > of work. I am sure it does "that's not how you are supposed to do it" > things, that worked perfectly fine for Magit but now have to be fixed. Can we "that's not how you are supposed to do it" things? I think that kind behavior puts some people of which is why successful packages are not added to Emacs but only reimplemented out of NIH. It does alienate many. > - I have just finished integrating it more tightly into Magit a few > months ago. That allowed me to rip out a lot of conditional code. > We would likely have to add that back and then some. > > - Future change in Magit might (or not, but it is a possibility) make > some significant changes necessary; I would hate it if the response > was "no" once/if I ask for those. > > In summary, git-commit.el works very well for me / Magit now. > Maintaining it is not much work anymore. This will change once this is > added to Emacs, at least initially, but potentially for years to come. > > This does conflict with my new year's resolution of avoiding to take on > any new work that has the potential of spiraling out of control. So I > would want someone else to do that work. > > That person would not only have to prepare git-commit.el for inclusion > in Emacs, they would also have to figure out how Magit can restore the > functionality lost in the process (by implementing the necessary "hooks" > in the bundled version *and* making use of them in Magit). Maybe it would be better to first work on the preceding items which you mentioned earlier that provide the functionality for git-commit to provide the features that it has. Simply adding some fontification and calling it a day does not seem like worthwhile effort to me.