Re: Adding git-commit highlight mode?

[Arsen Arsenović]

Stefan Kangas <stefankangas@gmail.com> writes:

> Arsen Arsenović <arsen@aarsen.me> writes:
>
>> A thing that a git commit mode ought to do, however, is set fill-column
>> to 72, highlight any content on line 2 as erroneous, and limit the first
>> line to 50 characters.  This is conventional in Git:
>> https://git-scm.com/docs/git-commit#_discussion
>> https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project.html#_commit_guidelines
>
> I agree with the 72 character fill-column, and have in the past
> suggested using that for ChangeLog's also.  (There was recently a
> decision to reduce the fill-column even further instead.)
>
> AFAICT, the 50 character line limit for the summary line is not really
> followed very strictly in practice by most projects, including the Linux
> kernel.  It's more of a recommendation.  Even the link you provide above
> says that it's "a good idea" to use "no more than 50 characters" for it.
> For that reason, I think that this should be a warning (with a highlight
> if you go over), and not a hard limit.

Right, I didn't mean hard limit.  I think Vim implements this well - it
stops coloring after column 50.  This isn't overly aggressive but is
still effective and handy.

> In `git-commit-mode`, the user option `git-commit-summary-max-length' is
> 68 by default, which strikes me as unopinionated enough.
>
>> As far as I know, some of these guidelines conflict with changelog
>> guidelines.
>
> They are not fundamentally incompatible, AFAIU.

I've been making them fit together, so I'm certain it is not fundamental
:-)

On that note, another interesting datapoint within GNU is GCC, which has
a particular commit message format.  Here's a random example from GCC:

commit 4ee692337c4ec18fe9be3df34f3607ea3de5ef93
Author: Jason Merrill

    c++: -fimplicit-constexpr diagnostic improvement [PR116696]
    
    PR116696 expressed surprise that explicit 'constexpr' was needed on one
    function; this was because the function isn't 'inline', and
    -fimplicit-constexpr doesn't try to promote non-inline functions.  Let's be
    more helpful in that situation, and also help trace through functions that
    were promoted.
    
            PR c++/116696
    
    gcc/cp/ChangeLog:
    
            * constexpr.cc (explain_invalid_constexpr_fn): When
            -fimplicit-constexpr, also explain inline functions, and point out
            non-inline functions.
    
    gcc/testsuite/ChangeLog:
    
            * g++.dg/DRs/dr2478.C: Prune extra diagnostic.
            * g++.dg/ext/fimplicit-constexpr1.C: New test.

Notice the ChangeLog segments towards the end, I'd appreciate if Emacs
handled these well.

Have a lovely year!
-- 
Arsen Arsenović

signature.asc
Description: PGP signature