Re: Adding git-commit highlight mode?

["Björn Bidar" <bjorn.bidar@thaodan.de>]

Jonas Bernoulli <jonas@bernoul.li> 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 <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.
>

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.