From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.devel Subject: Re: Adding git-commit highlight mode? Date: Sat, 04 Jan 2025 13:50:38 +0100 Message-ID: <87sepyeo9t.fsf@bernoul.li> References: <37733be4476e1c2b6e873c967c79cb0035959a9e.camel@yandex.ru> <083310b3-a288-5c75-c835-84595e134682@gmail.com> <56c9eadd95367cd3fd7c8414dc3e86b243a4b3d7.camel@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8947"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jim Porter , emacs-devel@gnu.org To: =?utf-8?Q?Bj=C3=B6rn?= Bidar , Konstantin Kharlamov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 04 14:28:24 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 1tU4CV-000213-Ri for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Jan 2025 14:28:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU4Bu-0000Xb-Ro; Sat, 04 Jan 2025 08:27:46 -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 1tU3c8-00083N-BX for emacs-devel@gnu.org; Sat, 04 Jan 2025 07:50:48 -0500 Original-Received: from mail.hostpark.net ([212.243.197.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tU3c5-0007fI-D0 for emacs-devel@gnu.org; Sat, 04 Jan 2025 07:50:48 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 8C6A81660B; Sat, 4 Jan 2025 13:50:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from; s=sel2011a; t=1735995040; bh=o7STT/xpvm2ILo9TY9PULcPFx7PJ+BQI2VLFzr1zId4=; b= O5XDsgV6VkRe4VLcbjnzA3lPA0L0Ih6+GRefKif7qvOXB9zbv47TztlbxYEtFOfK QbmioeZ917gnWjq/ZIbQHOvkGLHRAxfno7gSKhXcPyIeHmyJ+cUNho+uuwd4EbEf WU5+0MEf7zNJqS7PRyv0r+SF+v/HsVyXsYwM2u77Ju4= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id fkTngNGo384T; Sat, 4 Jan 2025 13:50:40 +0100 (CET) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 6551E161E1; Sat, 4 Jan 2025 13:50:39 +0100 (CET) In-Reply-To: <87v7uv9xub.fsf@> Received-SPF: pass client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 04 Jan 2025 08:27:43 -0500 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:327662 Archived-At: >> 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. 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). 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. 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. 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. 7. Setup commands for finishing and aborting the commit process in co-operation with magit and with-editor. 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. 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. - 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. - 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). And they would also have to figure out how Magit can continue to provide the same functionality for users of older Emacs releases. Adding git-commit.el to GNU ELPA might be an option here. Cheers, Jonas