Adding git-commit highlight mode?

Adding git-commit highlight mode?

[Konstantin Kharlamov]

Hi, just wanted to ask this before potentially taking on the initiative
to only find the code will get rejected.

I think a ballpark estimate of 90% of Git usage among CVSes in the
modern world is fair to assume.

But Emacs seems to be the only widely popular editor that still doesn't
provide OOTB at least syntax highlight for git-commit format. So, does
anyone have opposition to adding a major mode that would be bound to
filenames like `COMMIT_EDITMSG` and others, and would provide the
aforementioned highlight?

If there's no opposition, I could write such mode (it seems to be a
simple one), but I don't promise anything because Idk how long this
discussion will go and what's gonna happen tomorrow, etc… I just had
some spare time and motivation today, so decided to at least start the
discussion.

I don't have plans for adding complicated features besides just syntax
highlight. I think if anyone wishes they could be added later. And
indentation support from text-mode I think should be fine.

P.S.: to answer potential question "why not magit" — first it's not
OOTB experience. Second (but kinda related) it's a huge separate
package which takes off some startup time (and as of writing the words
commit highlight specifically doesn't work if you defer the load¹), but
not everyone needs full git-interaction suite in Emacs. Magit is great,
but I personally just grown over the years a bunch of zsh functions and
aliases that automate my Git workflow as much as possible, so I don't
think there's much to optimize still. I just want the highlight 😊 And
I think, having it in Emacs would benefit the wider community too.

1:
https://emacs.stackexchange.com/questions/82842/deferring-magit-load-without-breaking-highlight-in-git-commit

Re: Adding git-commit highlight mode?

[Eli Zaretskii]

> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Date: Thu, 02 Jan 2025 21:30:53 +0300
> 
> Hi, just wanted to ask this before potentially taking on the initiative
> to only find the code will get rejected.
> 
> I think a ballpark estimate of 90% of Git usage among CVSes in the
> modern world is fair to assume.
> 
> But Emacs seems to be the only widely popular editor that still doesn't
> provide OOTB at least syntax highlight for git-commit format. So, does
> anyone have opposition to adding a major mode that would be bound to
> filenames like `COMMIT_EDITMSG` and others, and would provide the
> aforementioned highlight?

FWIW, I have this in my ~/.emacs since about forever:

  (define-derived-mode text-with-comments-mode text-mode "Text#"
    "Text mode with comment syntax."
    (setq-local comment-start "#")
    (setq-local comment-start-skip
		(concat (regexp-quote comment-start) "+\\s *"))
    (setq-local font-lock-defaults '(nil nil t nil))
    (set-syntax-table
     (let ((table (make-syntax-table)))
       (modify-syntax-entry ?\# "<" table)
       table)))
  (add-to-list 'auto-mode-alist '("COMMIT_EDITMSG\\'" . text-with-comments-mode))

> If there's no opposition, I could write such mode (it seems to be a
> simple one), but I don't promise anything because Idk how long this
> discussion will go and what's gonna happen tomorrow, etc… I just had
> some spare time and motivation today, so decided to at least start the
> discussion.
> 
> I don't have plans for adding complicated features besides just syntax
> highlight. I think if anyone wishes they could be added later. And
> indentation support from text-mode I think should be fine.

Do you plan to make this mode be descendant of change-log-mode?
something else?

Re: Adding git-commit highlight mode?

[Konstantin Kharlamov]

On Thu, 2025-01-02 at 21:01 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > Date: Thu, 02 Jan 2025 21:30:53 +0300
> > 
> > Hi, just wanted to ask this before potentially taking on the
> > initiative
> > to only find the code will get rejected.
> > 
> > I think a ballpark estimate of 90% of Git usage among CVSes in the
> > modern world is fair to assume.
> > 
> > But Emacs seems to be the only widely popular editor that still
> > doesn't
> > provide OOTB at least syntax highlight for git-commit format. So,
> > does
> > anyone have opposition to adding a major mode that would be bound
> > to
> > filenames like `COMMIT_EDITMSG` and others, and would provide the
> > aforementioned highlight?
> 
> FWIW, I have this in my ~/.emacs since about forever:
> 
>   (define-derived-mode text-with-comments-mode text-mode "Text#"
>     "Text mode with comment syntax."
>     (setq-local comment-start "#")
>     (setq-local comment-start-skip
> 		(concat (regexp-quote comment-start) "+\\s *"))
>     (setq-local font-lock-defaults '(nil nil t nil))
>     (set-syntax-table
>      (let ((table (make-syntax-table)))
>        (modify-syntax-entry ?\# "<" table)
>        table)))
>   (add-to-list 'auto-mode-alist '("COMMIT_EDITMSG\\'" . text-with-
> comments-mode))
> 
> > If there's no opposition, I could write such mode (it seems to be a
> > simple one), but I don't promise anything because Idk how long this
> > discussion will go and what's gonna happen tomorrow, etc… I just
> > had
> > some spare time and motivation today, so decided to at least start
> > the
> > discussion.
> > 
> > I don't have plans for adding complicated features besides just
> > syntax
> > highlight. I think if anyone wishes they could be added later. And
> > indentation support from text-mode I think should be fine.
> 
> Do you plan to make this mode be descendant of change-log-mode?
> something else?

I thought of deriving from text-mode. I don't know much of change-log-
mode besides what it says in the mode title and now that I'm looking at
mode description it also sounds pretty vague. So… I could derive it
from change-log-mode if you think it's useful, but I'd rely on your
judgment here 😊

Re: Adding git-commit highlight mode?

[Jim Porter]

On 1/2/2025 10:30 AM, Konstantin Kharlamov wrote:
> But Emacs seems to be the only widely popular editor that still doesn't
> provide OOTB at least syntax highlight for git-commit format. So, does
> anyone have opposition to adding a major mode that would be bound to
> filenames like `COMMIT_EDITMSG` and others, and would provide the
> aforementioned highlight?

For what it's worth, I wrote a very simple package to do this for 
myself, since I don't use Magit. (I'm just so used to the Git command 
line that I've never taken the time to mess with Magit.)

https://github.com/jimporter/git-command-modes/

I'm happy to assign copyright to the FSF for this or to upstream this 
into the Emacs tree, or whatever people would like here.

Re: Adding git-commit highlight mode?

[Konstantin Kharlamov]

On Thu, 2025-01-02 at 11:17 -0800, Jim Porter wrote:
> On 1/2/2025 10:30 AM, Konstantin Kharlamov wrote:
> > But Emacs seems to be the only widely popular editor that still
> > doesn't
> > provide OOTB at least syntax highlight for git-commit format. So,
> > does
> > anyone have opposition to adding a major mode that would be bound
> > to
> > filenames like `COMMIT_EDITMSG` and others, and would provide the
> > aforementioned highlight?
> 
> For what it's worth, I wrote a very simple package to do this for 
> myself, since I don't use Magit. (I'm just so used to the Git command
> line that I've never taken the time to mess with Magit.)
> 
> https://github.com/jimporter/git-command-modes/
> 
> I'm happy to assign copyright to the FSF for this or to upstream this
> into the Emacs tree, or whatever people would like here.

Sounds great, I see you even got tests there! And you're the only
contributor, so yeah, I presume it would work just fine.

Re: Adding git-commit highlight mode?

[Stefan Kangas]

Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:

> On Thu, 2025-01-02 at 21:01 +0200, Eli Zaretskii wrote:
>> > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
>> > Date: Thu, 02 Jan 2025 21:30:53 +0300
>> >
>> > Hi, just wanted to ask this before potentially taking on the
>> > initiative
>> > to only find the code will get rejected.
>> >
>> > I think a ballpark estimate of 90% of Git usage among CVSes in the
>> > modern world is fair to assume.
>> >
>> > But Emacs seems to be the only widely popular editor that still
>> > doesn't
>> > provide OOTB at least syntax highlight for git-commit format. So,
>> > does
>> > anyone have opposition to adding a major mode that would be bound
>> > to
>> > filenames like `COMMIT_EDITMSG` and others, and would provide the
>> > aforementioned highlight?

It would be great to have something like that in Emacs by default,
indeed.  Even a simple mode with syntax highlighting would go a long
way.

Note that there is some prior work here, see `git-commit-mode' in
`magit`.  However, AFAIU, we recommend not looking at the implementation
if you want to implement something like it, for reasons of copyright.
The reason is that once you look at its implementation it's hard to
write something original enough to be able to copyright assign the
result to the Free Software Foundation, and even if it is original it
can still (under some circumstances) be considered a derivative work of
the code you have looked at.

You can look at its docstrings though.  Let me know if this is
interesting, and I'll happily share it with you off-list.

I'm copying in Jonas Bernoulli, in case he has any comments.

>> Do you plan to make this mode be descendant of change-log-mode?
>> something else?
>
> I thought of deriving from text-mode. I don't know much of change-log-
> mode besides what it says in the mode title and now that I'm looking at
> mode description it also sounds pretty vague. So… I could derive it
> from change-log-mode if you think it's useful, but I'd rely on your
> judgment here 😊

`change-log-mode` implements the anachronistic ChangeLog format favored
by GNU.  If the idea is to be useful to the 90% of the world that uses
Git, I'd recommend against inheriting from `change-log-mode`, because
99.99% or so of Git users do not use that format.

Granted, that figure might be something more like 99.9% when it comes to
GNU Emacs users specifically.

Re: Adding git-commit highlight mode?

[Eli Zaretskii]

> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Cc: emacs-devel@gnu.org
> Date: Thu, 02 Jan 2025 22:07:46 +0300
> 
> On Thu, 2025-01-02 at 21:01 +0200, Eli Zaretskii wrote:
> > Do you plan to make this mode be descendant of change-log-mode?
> > something else?
> 
> I thought of deriving from text-mode. I don't know much of change-log-
> mode besides what it says in the mode title and now that I'm looking at
> mode description it also sounds pretty vague. So… I could derive it
> from change-log-mode if you think it's useful, but I'd rely on your
> judgment here 😊

change-log-mode is also a derivative of text-mode.  Its advantage is
that it already provides font-lock for the style of log entries we
use.

Re: Adding git-commit highlight mode?

[Eli Zaretskii]

> Date: Thu, 2 Jan 2025 11:17:08 -0800
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 1/2/2025 10:30 AM, Konstantin Kharlamov wrote:
> > But Emacs seems to be the only widely popular editor that still doesn't
> > provide OOTB at least syntax highlight for git-commit format. So, does
> > anyone have opposition to adding a major mode that would be bound to
> > filenames like `COMMIT_EDITMSG` and others, and would provide the
> > aforementioned highlight?
> 
> For what it's worth, I wrote a very simple package to do this for 
> myself, since I don't use Magit. (I'm just so used to the Git command 
> line that I've never taken the time to mess with Magit.)
> 
> https://github.com/jimporter/git-command-modes/
> 
> I'm happy to assign copyright to the FSF for this or to upstream this 
> into the Emacs tree, or whatever people would like here.

I don't mind adding this, but please make sure the mode(s) for editing
log messages provide at least the features we have in change-log-mode.

Thanks.

Re: Adding git-commit highlight mode?

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 2 Jan 2025 14:10:22 -0600
> Cc: emacs-devel@gnu.org, Jonas Bernoulli <jonas@bernoul.li>
> 
> > I thought of deriving from text-mode. I don't know much of change-log-
> > mode besides what it says in the mode title and now that I'm looking at
> > mode description it also sounds pretty vague. So… I could derive it
> > from change-log-mode if you think it's useful, but I'd rely on your
> > judgment here 😊
> 
> `change-log-mode` implements the anachronistic ChangeLog format favored
> by GNU.

That "anachronistic format" allows plain text, so I don't quite see
how using change-log-mode as the parent mode will cause us lose
anything?  What's the harm in getting everything text-mode descendants
can do, plus support for "anachronistic" formats?

Re: Adding git-commit highlight mode?

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
>> Cc: emacs-devel@gnu.org
>> Date: Thu, 02 Jan 2025 22:07:46 +0300
>> 
>> On Thu, 2025-01-02 at 21:01 +0200, Eli Zaretskii wrote:
>> > Do you plan to make this mode be descendant of change-log-mode?
>> > something else?
>> 
>> I thought of deriving from text-mode. I don't know much of change-log-
>> mode besides what it says in the mode title and now that I'm looking at
>> mode description it also sounds pretty vague. So… I could derive it
>> from change-log-mode if you think it's useful, but I'd rely on your
>> judgment here 😊
>
> change-log-mode is also a derivative of text-mode.  Its advantage is
> that it already provides font-lock for the style of log entries we
> use.

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

Naturally, all of this ought to be configurable, but these are important
features and sane defaults, and are one of the primary reasons why I
initially installed magit (though, I now use it for general Git
interaction while editing).

As far as I know, some of these guidelines conflict with changelog
guidelines.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: Adding git-commit highlight mode?

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Thu, 2 Jan 2025 14:10:22 -0600
>> Cc: emacs-devel@gnu.org, Jonas Bernoulli <jonas@bernoul.li>
>>
>> > I thought of deriving from text-mode. I don't know much of change-log-
>> > mode besides what it says in the mode title and now that I'm looking at
>> > mode description it also sounds pretty vague. So… I could derive it
>> > from change-log-mode if you think it's useful, but I'd rely on your
>> > judgment here 😊
>>
>> `change-log-mode` implements the anachronistic ChangeLog format favored
>> by GNU.
>
> That "anachronistic format" allows plain text, so I don't quite see
> how using change-log-mode as the parent mode will cause us lose
> anything?  What's the harm in getting everything text-mode descendants
> can do, plus support for "anachronistic" formats?

I'm concerned that it would get in the way of editing commit messages
that do not use the ChangeLog format.  It seems to me that
`change-log-mode' would need quite a bit of adapting not to do that.
For example, `open-line` in that mode adds a tab character at the
beginning of the line.  It would also contribute to some confusion, when
users try to figure out what ChangeLog's are, and why they are needed to
use Git.

Instead of inheriting from it, I'd propose creating an optional minor
mode, that users can enabled when they need to, plus a globalized mode
for those that want it on always.  That would also expand it to be
useful also with Magit's `git-commit-mode`, for example, which I'd
personally welcome.  (FWIW, I happen to think that the paragraph filling
rules would be the most interesting feature in such a minor mode.)

Re: Adding git-commit highlight mode?

[Konstantin Kharlamov]

On Thu, 2025-01-02 at 14:10 -0600, Stefan Kangas wrote:
> Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:
> 
> > On Thu, 2025-01-02 at 21:01 +0200, Eli Zaretskii wrote:
> > > > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > > > Date: Thu, 02 Jan 2025 21:30:53 +0300
> > > > 
> > > > Hi, just wanted to ask this before potentially taking on the
> > > > initiative
> > > > to only find the code will get rejected.
> > > > 
> > > > I think a ballpark estimate of 90% of Git usage among CVSes in
> > > > the
> > > > modern world is fair to assume.
> > > > 
> > > > But Emacs seems to be the only widely popular editor that still
> > > > doesn't
> > > > provide OOTB at least syntax highlight for git-commit format.
> > > > So,
> > > > does
> > > > anyone have opposition to adding a major mode that would be
> > > > bound
> > > > to
> > > > filenames like `COMMIT_EDITMSG` and others, and would provide
> > > > the
> > > > aforementioned highlight?
> 
> It would be great to have something like that in Emacs by default,
> indeed.  Even a simple mode with syntax highlighting would go a long
> way.
> 
> Note that there is some prior work here, see `git-commit-mode' in
> `magit`.  However, AFAIU, we recommend not looking at the
> implementation
> if you want to implement something like it, for reasons of copyright.
> The reason is that once you look at its implementation it's hard to
> write something original enough to be able to copyright assign the
> result to the Free Software Foundation, and even if it is original it
> can still (under some circumstances) be considered a derivative work
> of
> the code you have looked at.

Thank you! Yeah, I figured I shouldn't look at magit for license
reasons,  so I was going to use VSCode's syntax highlight as a
reference¹, since nowadays, at least from looking at other people, it
seems to be the most popular editor, so presumably its support should
be good.

However, for now I'm assuming Jim is taking over the initiative as he
has already written the mode.

1:
https://github.com/microsoft/vscode/tree/2bdb3e9b41bd72048ea2067a350d8536c82fc7f6/extensions/git-base

Re: Adding git-commit highlight mode?

[Stefan Kangas]

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.

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.

Re: Adding git-commit highlight mode?

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]

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ć

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: Adding git-commit highlight mode?

[Jim Porter]

On 1/2/2025 1:38 PM, Stefan Kangas wrote:
> Instead of inheriting from it, I'd propose creating an optional minor
> mode, that users can enabled when they need to, plus a globalized mode
> for those that want it on always.  That would also expand it to be
> useful also with Magit's `git-commit-mode`, for example, which I'd
> personally welcome.  (FWIW, I happen to think that the paragraph filling
> rules would be the most interesting feature in such a minor mode.)

You took the words out of my mouth. :) I'm not sure about all the 
details here, but some way of "embedding" change-log-mode into other 
major modes would be really helpful. Maybe there are other ways to do 
this instead, like multi-major-mode support (e.g. in html-mode and the 
like), but I think it makes sense not to *require* change-log-mode if it 
could get in the way for users who don't write commits like that.

Re: Adding git-commit highlight mode?

[Jim Porter]

On 1/2/2025 1:40 PM, Konstantin Kharlamov wrote:
> However, for now I'm assuming Jim is taking over the initiative as he
> has already written the mode.

We'll see. :) So long as we can agree on what to do about 
change-log-mode, I don't mind finishing up my code for inclusion in 
Emacs. I don't have any opinions here since I know next to nothing about 
change-log-mode.

The other major-mode my code provides is one for interactive rebasing, 
so that there are keybindings for squashing and reordering commits and 
such. I find that particularly useful since I rebase pretty much constantly.

Re: Adding git-commit highlight mode?

[Eli Zaretskii]

> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: Konstantin Kharlamov <Hi-Angel@yandex.ru>,  emacs-devel@gnu.org
> Date: Thu, 02 Jan 2025 22:19:47 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> >> Cc: emacs-devel@gnu.org
> >> Date: Thu, 02 Jan 2025 22:07:46 +0300
> >> 
> >> On Thu, 2025-01-02 at 21:01 +0200, Eli Zaretskii wrote:
> >> > Do you plan to make this mode be descendant of change-log-mode?
> >> > something else?
> >> 
> >> I thought of deriving from text-mode. I don't know much of change-log-
> >> mode besides what it says in the mode title and now that I'm looking at
> >> mode description it also sounds pretty vague. So… I could derive it
> >> from change-log-mode if you think it's useful, but I'd rely on your
> >> judgment here 😊
> >
> > change-log-mode is also a derivative of text-mode.  Its advantage is
> > that it already provides font-lock for the style of log entries we
> > use.
> 
> 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
> 
> Naturally, all of this ought to be configurable, but these are important
> features and sane defaults, and are one of the primary reasons why I
> initially installed magit (though, I now use it for general Git
> interaction while editing).
> 
> As far as I know, some of these guidelines conflict with changelog
> guidelines.

Being a descendant of change-log-mode doesn't mean the derivative mode
cannot change the settings it needs to change.  ChangeLog files are
indented, whereas commit log messages aren't, so some customization of
the whitespace and fill-column will sure be needed.  But, for example,
the change-log-fill-parenthesized-list capability will come in very
handy.

Re: Adding git-commit highlight mode?

[Jonas Bernoulli]

> I'm copying in Jonas Bernoulli, in case he has any comments.

I was under the impression that log-edit.el is Emacs's git-commit.el.
I haven't looked at it in a long time, so maybe I don't remember this
correctly, but doesn't that cover about the same ground?  Modulo some
quality of life improvements and bells and whistles maybe. 

One idea from git-commit.el that you might want to adapt in your
alternative is to *not* center the package around a single major-mode.
git-commit.el instead adds to find-file-hook a function, which checks if
the visited file is one of those files used by Git to have to user write
a commit message.  If so, it enables the *minor*-mode git-commit-mode
(which adds some additional font-lock and key bindings) but first *some*
major-mode.  The major-mode can be different for different repositories,
which is quite useful, considering that different projects follow vastly
different commit message conventions.

     Cheers,
     Jonas

Re: Adding git-commit highlight mode?

[Sean Whitton]

Hello,

On Thu 02 Jan 2025 at 03:53pm -06, Stefan Kangas wrote:

> 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.
>
> In `git-commit-mode`, the user option `git-commit-summary-max-length' is
> 68 by default, which strikes me as unopinionated enough.

As Jonas mentioned, some of the things suggested in this thread overlap
with our existing vc-git-log-edit-mode.  For example, we already have
vc-git-log-edit-summary-target-len and vc-git-log-edit-summary-max-len.

I haven't looked at your code, Jim, but hopefully it could avoid too
much reimplementation/crossover with vc-git-log-edit-mode if we are
going to put it in emacs.git.
I will happily review what you'd actually like to include.

(As the VC maintainer, I would have appreciated being CC'd on this
thread at some point; glad I caught it anyway.)

-- 
Sean Whitton

Re: Adding git-commit highlight mode?

[Björn Bidar]

Jim Porter <jporterbugs@gmail.com> writes:

> On 1/2/2025 10:30 AM, Konstantin Kharlamov wrote:
>> But Emacs seems to be the only widely popular editor that still doesn't
>> provide OOTB at least syntax highlight for git-commit format. So, does
>> anyone have opposition to adding a major mode that would be bound to
>> filenames like `COMMIT_EDITMSG` and others, and would provide the
>> aforementioned highlight?
>
> For what it's worth, I wrote a very simple package to do this for
> myself, since I don't use Magit. (I'm just so used to the Git command
> line that I've never taken the time to mess with Magit.)
>

Is there a way we can do this without reinventing the wheel? E.g. by
including Jonas's git-commit mode into Emacs?

PS: It would be very beneficial to not uses Github for Emacs
development but other FOSS platforms such as Codeberg. No need to feed
Copilot with our code to copy it into other non-FOSS code.

Re: Adding git-commit highlight mode?

[Konstantin Kharlamov]

On Fri, 2025-01-03 at 23:14 +0200, Björn Bidar wrote:
> Jim Porter <jporterbugs@gmail.com> writes:
> 
> > On 1/2/2025 10:30 AM, Konstantin Kharlamov wrote:
> > > But Emacs seems to be the only widely popular editor that still
> > > doesn't
> > > provide OOTB at least syntax highlight for git-commit format. So,
> > > does
> > > anyone have opposition to adding a major mode that would be bound
> > > to
> > > filenames like `COMMIT_EDITMSG` and others, and would provide the
> > > aforementioned highlight?
> > 
> > For what it's worth, I wrote a very simple package to do this for
> > myself, since I don't use Magit. (I'm just so used to the Git
> > command
> > line that I've never taken the time to mess with Magit.)
> > 
> 
> Is there a way we can do this without reinventing the wheel? E.g. by
> including Jonas's git-commit mode into Emacs?

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.

> PS: It would be very beneficial to not uses Github for Emacs
> development but other FOSS platforms such as Codeberg. No need to
> feed
> Copilot with our code to copy it into other non-FOSS code.

As mentioned by Dick, Emacs is mirrored to Github anyway. From my
search it seems neither Codeberg nor Gitlab has an active Emacs mirror,
right? That means there's no other option besides Github for
contributors to store their local changes to before sending them
upstream. Obviously, a new contributor wouldn't have an account to
git.savannah, and even if they do, git.savannah doesn't allow to fork a
repo, instead it requires to store everyone the changes to their local
branch on a shared repo, which seems unsafe on a bigger scale.

Re: Adding git-commit highlight mode?

[Björn Bidar]

Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:

> On Fri, 2025-01-03 at 23:14 +0200, Björn Bidar wrote:
>> Jim Porter <jporterbugs@gmail.com> writes:
>> 
>> > On 1/2/2025 10:30 AM, Konstantin Kharlamov wrote:
>> > > But Emacs seems to be the only widely popular editor that still
>> > > doesn't
>> > > provide OOTB at least syntax highlight for git-commit format. So,
>> > > does
>> > > anyone have opposition to adding a major mode that would be bound
>> > > to
>> > > filenames like `COMMIT_EDITMSG` and others, and would provide the
>> > > aforementioned highlight?
>> > 
>> > For what it's worth, I wrote a very simple package to do this for
>> > myself, since I don't use Magit. (I'm just so used to the Git
>> > command
>> > line that I've never taken the time to mess with Magit.)
>> > 
>> 
>> Is there a way we can do this without reinventing the wheel? E.g. by
>> including Jonas's git-commit mode into Emacs?
>
> 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.


>> PS: It would be very beneficial to not uses Github for Emacs
>> development but other FOSS platforms such as Codeberg. No need to
>> feed
>> Copilot with our code to copy it into other non-FOSS code.
>
> As mentioned by Dick, Emacs is mirrored to Github anyway.

Dicks rather trolling comment aside, I don't think that is a reason to
use Github.

> search it seems neither Codeberg nor Gitlab has an active Emacs mirror,
> right?
> That means there's no other option besides Github for
> contributors to store their local changes to before sending them
> upstream.

I don't see a problem there, create an account on which server you prefer and fetch from Savannah.
No need to use Github to download the Emacs repository.

> Obviously, a new contributor wouldn't have an account to
> git.savannah, and even if they do, git.savannah doesn't allow to fork a
> repo, instead it requires to store everyone the changes to their local
> branch on a shared repo, which seems unsafe on a bigger scale.

This has nothing to do with Savannah, you don't have to "fork" a
repository that's a Forge thing to map pull requests (and to easier map
commit refs between the source and the fork but that's OT).

Re: Adding git-commit highlight mode?

[Konstantin Kharlamov]

On Sat, 2025-01-04 at 03:22 +0200, Björn Bidar wrote:
> Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:
> 
> > On Fri, 2025-01-03 at 23:14 +0200, Björn Bidar wrote:
> > > Jim Porter <jporterbugs@gmail.com> writes:
> > > 
> > > > On 1/2/2025 10:30 AM, Konstantin Kharlamov wrote:
> > > > > But Emacs seems to be the only widely popular editor that
> > > > > still
> > > > > doesn't
> > > > > provide OOTB at least syntax highlight for git-commit format.
> > > > > So,
> > > > > does
> > > > > anyone have opposition to adding a major mode that would be
> > > > > bound
> > > > > to
> > > > > filenames like `COMMIT_EDITMSG` and others, and would provide
> > > > > the
> > > > > aforementioned highlight?
> > > > 
> > > > For what it's worth, I wrote a very simple package to do this
> > > > for
> > > > myself, since I don't use Magit. (I'm just so used to the Git
> > > > command
> > > > line that I've never taken the time to mess with Magit.)
> > > > 
> > > 
> > > Is there a way we can do this without reinventing the wheel? E.g.
> > > by
> > > including Jonas's git-commit mode into Emacs?
> > 
> > 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.

If you open this link
https://github.com/magit/magit/blame/main/lisp/git-commit.el and look
at the "contributors" text, it says "24". I think contacting 23
different people is so much work that you can rewrite the syntax
highlight 5 times and still get spare time.

> > > PS: It would be very beneficial to not uses Github for Emacs
> > > development but other FOSS platforms such as Codeberg. No need to
> > > feed
> > > Copilot with our code to copy it into other non-FOSS code.
> > 
> > As mentioned by Dick, Emacs is mirrored to Github anyway.
> 
> Dicks rather trolling comment aside, I don't think that is a reason
> to
> use Github.
> 
> > search it seems neither Codeberg nor Gitlab has an active Emacs
> > mirror,
> > right?
> > That means there's no other option besides Github for
> > contributors to store their local changes to before sending them
> > upstream.
> 
> I don't see a problem there, create an account on which server you
> prefer and fetch from Savannah.
> No need to use Github to download the Emacs repository.

I guess you're right.

> > Obviously, a new contributor wouldn't have an account to
> > git.savannah, and even if they do, git.savannah doesn't allow to
> > fork a
> > repo, instead it requires to store everyone the changes to their
> > local
> > branch on a shared repo, which seems unsafe on a bigger scale.
> 
> This has nothing to do with Savannah, you don't have to "fork" a
> repository that's a Forge thing to map pull requests (and to easier
> map
> commit refs between the source and the fork but that's OT).

Forking is a solution to the problem where you don't want to grant an
arbitrary person write access to a git repo. Though now that I think,
theoretically it may be possible to implement similar workflow by only
granting access to the `username/` sub-tree. Access management is done
by a harness around git, and one can write it any way they want. Either
way, I don't think such access management has been implemented by
anyone, whereas "forking" workflow does have implementations.

Re: Adding git-commit highlight mode?

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Fri, 03 Jan 2025 21:02:21 +0000
> 
> Hello,
> 
> On Thu 02 Jan 2025 at 03:53pm -06, Stefan Kangas wrote:
> 
> > 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.
> >
> > In `git-commit-mode`, the user option `git-commit-summary-max-length' is
> > 68 by default, which strikes me as unopinionated enough.
> 
> As Jonas mentioned, some of the things suggested in this thread overlap
> with our existing vc-git-log-edit-mode.  For example, we already have
> vc-git-log-edit-summary-target-len and vc-git-log-edit-summary-max-len.

vc-git-log-edit-mode kicks in only if one commits using VC commands.
It will not kick in if, for example, one commits from the shell prompt
with GIT_EDITOR set to invoke emacsclient.

So there's still a place for a mode that is turned on when Emacs needs
to edit the files with special names used by Git for some of the
activities.

> (As the VC maintainer, I would have appreciated being CC'd on this
> thread at some point; glad I caught it anyway.)

The thread was not about VC (still isn't, AFAICT), so it is not
surprising you were not CC'ed.

Re: Adding git-commit highlight mode?

[Sean Whitton]

Hello,

On Sat 04 Jan 2025 at 09:17am +02, Eli Zaretskii wrote:

> vc-git-log-edit-mode kicks in only if one commits using VC commands.
> It will not kick in if, for example, one commits from the shell prompt
> with GIT_EDITOR set to invoke emacsclient.
>
> So there's still a place for a mode that is turned on when Emacs needs
> to edit the files with special names used by Git for some of the
> activities.

Right, but ideally there could be some code reuse.

>> (As the VC maintainer, I would have appreciated being CC'd on this
>> thread at some point; glad I caught it anyway.)
>
> The thread was not about VC (still isn't, AFAICT), so it is not
> surprising you were not CC'ed.

It's closely enough related that I would have appreciated it.

-- 
Sean Whitton

Re: Adding git-commit highlight mode?

[Jonas Bernoulli]

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

Re: Adding git-commit highlight mode?

[Jonas Bernoulli]

Jonas Bernoulli <jonas@bernoul.li> writes:

> 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.

I've done that see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=+75355.

Re: Adding git-commit highlight mode?

[Björn Bidar]

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.

Re: Adding git-commit highlight mode?

[Björn Bidar]

Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:

> Hi, just wanted to ask this before potentially taking on the initiative
> to only find the code will get rejected.
>
> I think a ballpark estimate of 90% of Git usage among CVSes in the
> modern world is fair to assume.
>
> But Emacs seems to be the only widely popular editor that still doesn't
> provide OOTB at least syntax highlight for git-commit format.

Does it do that if you use Emacs to commit? I.e. use VC?

> So, does
> anyone have opposition to adding a major mode that would be bound to
> filenames like `COMMIT_EDITMSG` and others, and would provide the
> aforementioned highlight?

The question is how would that benefit someone besides those that do
not VC nor Magit. The mechanism of calling git commit having Emacs
depends at least on with-editor which makes likely that the user would
use magit or maybe vc (IDK).

>
> P.S.: to answer potential question "why not magit" — first it's not
> OOTB experience. Second (but kinda related) it's a huge separate
> package which takes off some startup time (and as of writing the words
> commit highlight specifically doesn't work if you defer the load¹), but
> not everyone needs full git-interaction suite in Emacs. Magit is great,
> but I personally just grown over the years a bunch of zsh functions and
> aliases that automate my Git workflow as much as possible, so I don't
> think there's much to optimize still. I just want the highlight 😊 And
> I think, having it in Emacs would benefit the wider community too.

I might be that you load magit wrong since you seem to add :defer t to
your configuration but also very likely use other options such as :bind
which also enable deferred loading. That could mess up things.

> 1:
> https://emacs.stackexchange.com/questions/82842/deferring-magit-load-without-breaking-highlight-in-git-commit

Re: Adding git-commit highlight mode?

[Björn Bidar]

Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:

> On Sat, 2025-01-04 at 03:22 +0200, Björn Bidar wrote:
>> Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:
>> 
>> > On Fri, 2025-01-03 at 23:14 +0200, Björn Bidar wrote:
>> > > Jim Porter <jporterbugs@gmail.com> writes:
>> > > 
>> > > > On 1/2/2025 10:30 AM, Konstantin Kharlamov wrote:
>> > > > > But Emacs seems to be the only widely popular editor that
>> > > > > still
>> > > > > doesn't
>> > > > > provide OOTB at least syntax highlight for git-commit format.
>> > > > > So,
>> > > > > does
>> > > > > anyone have opposition to adding a major mode that would be
>> > > > > bound
>> > > > > to
>> > > > > filenames like `COMMIT_EDITMSG` and others, and would provide
>> > > > > the
>> > > > > aforementioned highlight?
>> > > > 
>> > > > For what it's worth, I wrote a very simple package to do this
>> > > > for
>> > > > myself, since I don't use Magit. (I'm just so used to the Git
>> > > > command
>> > > > line that I've never taken the time to mess with Magit.)
>> > > > 
>> > > 
>> > > Is there a way we can do this without reinventing the wheel? E.g.
>> > > by
>> > > including Jonas's git-commit mode into Emacs?
>> > 
>> > 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.
>
> If you open this link
> https://github.com/magit/magit/blame/main/lisp/git-commit.el and look
> at the "contributors" text, it says "24". I think contacting 23
> different people is so much work that you can rewrite the syntax
> highlight 5 times and still get spare time.

Jonas replied to to this comment better than me already.

>> > > PS: It would be very beneficial to not uses Github for Emacs
>> > > development but other FOSS platforms such as Codeberg. No need to
>> > > feed
>> > > Copilot with our code to copy it into other non-FOSS code.
>> > 
>> > As mentioned by Dick, Emacs is mirrored to Github anyway.
>> 
>> Dicks rather trolling comment aside, I don't think that is a reason
>> to
>> use Github.
>> 
>> > search it seems neither Codeberg nor Gitlab has an active Emacs
>> > mirror,
>> > right?
>> > That means there's no other option besides Github for
>> > contributors to store their local changes to before sending them
>> > upstream.
>> 
>> I don't see a problem there, create an account on which server you
>> prefer and fetch from Savannah.
>> No need to use Github to download the Emacs repository.
>
> I guess you're right.
>
>> > Obviously, a new contributor wouldn't have an account to
>> > git.savannah, and even if they do, git.savannah doesn't allow to
>> > fork a
>> > repo, instead it requires to store everyone the changes to their
>> > local
>> > branch on a shared repo, which seems unsafe on a bigger scale.
>> 
>> This has nothing to do with Savannah, you don't have to "fork" a
>> repository that's a Forge thing to map pull requests (and to easier
>> map
>> commit refs between the source and the fork but that's OT).
>
> Forking is a solution to the problem where you don't want to grant an
> arbitrary person write access to a git repo. Though now that I think,
> theoretically it may be possible to implement similar workflow by only
> granting access to the `username/` sub-tree. Access management is done
> by a harness around git, and one can write it any way they want. Either
> way, I don't think such access management has been implemented by
> anyone, whereas "forking" workflow does have implementations.

You misunderstand me: You don't have "fork" anything, just create new
repository with your desired name and fetch from which source you
prefer.
None of the "forking" workflow applies to Emacs development and fetching/cloning
of repositories can be done without "forking".
Just clone emacs.git and add your own remote, done.

Re: Adding git-commit highlight mode?

[Konstantin Kharlamov]

On Sun, 2025-01-05 at 02:42 +0200, Björn Bidar wrote:
> Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:
> 
> > Hi, just wanted to ask this before potentially taking on the
> > initiative
> > to only find the code will get rejected.
> > 
> > I think a ballpark estimate of 90% of Git usage among CVSes in the
> > modern world is fair to assume.
> > 
> > But Emacs seems to be the only widely popular editor that still
> > doesn't
> > provide OOTB at least syntax highlight for git-commit format.
> 
> Does it do that if you use Emacs to commit? I.e. use VC?

I didn't try using VC as I don't know its functions to commit. But it's
tangentially related (I have well optimized workflow with zsh, so I
wouldn't need VC nor Magit): do you know that it has the highlight?

> > So, does
> > anyone have opposition to adding a major mode that would be bound
> > to
> > filenames like `COMMIT_EDITMSG` and others, and would provide the
> > aforementioned highlight?
> 
> The question is how would that benefit someone besides those that do
> not VC nor Magit. The mechanism of calling git commit having Emacs
> depends at least on with-editor which makes likely that the user
> would
> use magit or maybe vc (IDK).

Idk. I'm thinking here about the usecase where emacsclient is called as
an editor, which I think is popular too.

> > 
> > P.S.: to answer potential question "why not magit" — first it's not
> > OOTB experience. Second (but kinda related) it's a huge separate
> > package which takes off some startup time (and as of writing the
> > words
> > commit highlight specifically doesn't work if you defer the load¹),
> > but
> > not everyone needs full git-interaction suite in Emacs. Magit is
> > great,
> > but I personally just grown over the years a bunch of zsh functions
> > and
> > aliases that automate my Git workflow as much as possible, so I
> > don't
> > think there's much to optimize still. I just want the highlight 😊
> > And
> > I think, having it in Emacs would benefit the wider community too.
> 
> I might be that you load magit wrong since you seem to add :defer t
> to
> your configuration but also very likely use other options such as
> :bind
> which also enable deferred loading. That could mess up things.

No, I don't use :bind. I only have :init and :config sections.

Re: Adding git-commit highlight mode?

[Konstantin Kharlamov]

On Sun, 2025-01-05 at 02:46 +0200, Björn Bidar wrote:
> You misunderstand me: You don't have "fork" anything, just create new
> repository with your desired name and fetch from which source you
> prefer.
> None of the "forking" workflow applies to Emacs development and
> fetching/cloning
> of repositories can be done without "forking".
> Just clone emacs.git and add your own remote, done.

I see, you're probably right. I guess it's just laziness on my side: I
contribute somewhere ± every week, and pressing "fork" button, and then
reverse-searching from zsh history a `git remote add origin
<domain>/Hi-Angel/<proj_name>` and replacing <proj_name> with the new
one is very fast.