Re: Adding git-commit highlight mode?

[Jonas Bernoulli <jonas@bernoul.li>]

>> 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 <email>"

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