Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Po Lu]

Yuan Fu <casouri@gmail.com> writes:

> branch: emacs-30
> commit f0daa2f2153a9d250d32ac1261a6fffb30860e31
> Author: Yuan Fu <casouri@gmail.com>
> Commit: Yuan Fu <casouri@gmail.com>
>
>     Conservative heuristic for tree-sitter parser ranges (bug#73324)
>     
>     * src/treesit.c (treesit_sync_visible_region): If the parser's original
>     ranges don't overlap with visible region, give it a zero range, rather
>     than don't set any range.
>     * test/src/treesit-tests.el (treesit-range-fixup-after-edit): Test new
>     behavior.

Please fill ChangeLog entries in commit messages to a width of 64
columns, not 71 or 72, as here.

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Yuan Fu]

> On Sep 17, 2024, at 11:31 PM, Po Lu <luangruo@yahoo.com> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>> branch: emacs-30
>> commit f0daa2f2153a9d250d32ac1261a6fffb30860e31
>> Author: Yuan Fu <casouri@gmail.com>
>> Commit: Yuan Fu <casouri@gmail.com>
>> 
>>    Conservative heuristic for tree-sitter parser ranges (bug#73324)
>> 
>>    * src/treesit.c (treesit_sync_visible_region): If the parser's original
>>    ranges don't overlap with visible region, give it a zero range, rather
>>    than don't set any range.
>>    * test/src/treesit-tests.el (treesit-range-fixup-after-edit): Test new
>>    behavior.
> 
> Please fill ChangeLog entries in commit messages to a width of 64
> columns, not 71 or 72, as here.

Oh ok. Got it. But 80 for the title?

Yuan

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 19 Sep 2024 21:53:40 -0700
> Cc: emacs-devel@gnu.org
> 
> > Please fill ChangeLog entries in commit messages to a width of 64
> > columns, not 71 or 72, as here.
> 
> Oh ok. Got it. But 80 for the title?

No, 74.  Because the title is also indented by a TAB in the generated
ChangeLog file, and it should end up the same width as the entries.

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Eli Zaretskii]

> Date: Fri, 20 Sep 2024 09:32:44 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> 
> > From: Yuan Fu <casouri@gmail.com>
> > Date: Thu, 19 Sep 2024 21:53:40 -0700
> > Cc: emacs-devel@gnu.org
> > 
> > > Please fill ChangeLog entries in commit messages to a width of 64
> > > columns, not 71 or 72, as here.
> > 
> > Oh ok. Got it. But 80 for the title?
> 
> No, 74.  Because the title is also indented by a TAB in the generated
      ^^
Sorry, that was supposed to be 64, not 74.

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Yuan Fu]

> On Sep 19, 2024, at 11:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Date: Fri, 20 Sep 2024 09:32:44 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
>> 
>>> From: Yuan Fu <casouri@gmail.com>
>>> Date: Thu, 19 Sep 2024 21:53:40 -0700
>>> Cc: emacs-devel@gnu.org
>>> 
>>>> Please fill ChangeLog entries in commit messages to a width of 64
>>>> columns, not 71 or 72, as here.
>>> 
>>> Oh ok. Got it. But 80 for the title?
>> 
>> No, 74.  Because the title is also indented by a TAB in the generated
>      ^^
> Sorry, that was supposed to be 64, not 74.

Cool, thanks for the info!

Yuan

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Yuan Fu <casouri@gmail.com> writes:
>
>> branch: emacs-30
>> commit f0daa2f2153a9d250d32ac1261a6fffb30860e31
>> Author: Yuan Fu <casouri@gmail.com>
>> Commit: Yuan Fu <casouri@gmail.com>
>>
>>     Conservative heuristic for tree-sitter parser ranges (bug#73324)
>>
>>     * src/treesit.c (treesit_sync_visible_region): If the parser's original
>>     ranges don't overlap with visible region, give it a zero range, rather
>>     than don't set any range.
>>     * test/src/treesit-tests.el (treesit-range-fixup-after-edit): Test new
>>     behavior.
>
> Please fill ChangeLog entries in commit messages to a width of 64
> columns, not 71 or 72, as here.

I don't want to get into another argument about this, but I don't see
any problem with the above formatting, FWIW.

In any case, I really don't think it is a good use of our time to police
the recently introduced default of 64 columns here.  We never did that
before, when the default in `vc-git-log-edit-mode' was 70 characters,
and there is no reason to start doing it now.

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 21 Sep 2024 17:59:08 -0700
> Cc: Yuan Fu <casouri@gmail.com>
> 
> In any case, I really don't think it is a good use of our time to police
> the recently introduced default of 64 columns here.  We never did that
> before, when the default in `vc-git-log-edit-mode' was 70 characters,
> and there is no reason to start doing it now.

I don't police it, but when I install someone's changes, I frequently
reformat the log entries to be short enough.  It would be nice if I
had to do this less than I do now.

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

>> Please fill ChangeLog entries in commit messages to a width of 64
>> columns, not 71 or 72, as here.
>
> I don't want to get into another argument about this, but I don't see
> any problem with the above formatting, FWIW.
>
> In any case, I really don't think it is a good use of our time to police

It is a good (and a exceedingly slight) use of my time.

> the recently introduced default of 64 columns here.  We never did that
> before, when the default in `vc-git-log-edit-mode' was 70 characters,
> and there is no reason to start doing it now.

That point is moot when most of us were self-consciously observing this
standard before it was formalized in .dir-locals.el.

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Yuan Fu]

> On Sep 21, 2024, at 10:43 PM, Po Lu <luangruo@yahoo.com> wrote:
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
>>> Please fill ChangeLog entries in commit messages to a width of 64
>>> columns, not 71 or 72, as here.
>> 
>> I don't want to get into another argument about this, but I don't see
>> any problem with the above formatting, FWIW.
>> 
>> In any case, I really don't think it is a good use of our time to police
> 
> It is a good (and a exceedingly slight) use of my time.
> 
>> the recently introduced default of 64 columns here.  We never did that
>> before, when the default in `vc-git-log-edit-mode' was 70 characters,
>> and there is no reason to start doing it now.
> 
> That point is moot when most of us were self-consciously observing this
> standard before it was formalized in .dir-locals.el.

I took a look and it’s set for log-edit-mode only. It would be nice if magit can pick it up. I’m sure a lot of people (me included) use magit for developing Emacs. The only problem is magit’s commit message editing buffer doesn’t have a special major mode. It does git-commit-mode which is a minor mode, and runs git-commit-setup-hook. But I’m not sure how to edit dir-locals to set fill-column using a hook or minor mode.

Yuan

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Kévin Le Gouguec]

Yuan Fu <casouri@gmail.com> writes:

>> On Sep 21, 2024, at 10:43 PM, Po Lu <luangruo@yahoo.com> wrote:
>> 
>> Stefan Kangas <stefankangas@gmail.com> writes:
>> 
>>>> Please fill ChangeLog entries in commit messages to a width of 64
>>>> columns, not 71 or 72, as here.
>>> 
>>> I don't want to get into another argument about this, but I don't see
>>> any problem with the above formatting, FWIW.
>>> 
>>> In any case, I really don't think it is a good use of our time to police
>> 
>> It is a good (and a exceedingly slight) use of my time.
>> 
>>> the recently introduced default of 64 columns here.  We never did that
>>> before, when the default in `vc-git-log-edit-mode' was 70 characters,
>>> and there is no reason to start doing it now.
>> 
>> That point is moot when most of us were self-consciously observing this
>> standard before it was formalized in .dir-locals.el.
>
> I took a look and it’s set for log-edit-mode only. It would be nice if magit can pick it up. I’m sure a lot of people (me included) use magit for developing Emacs. The only problem is magit’s commit message editing buffer doesn’t have a special major mode. It does git-commit-mode which is a minor mode, and runs git-commit-setup-hook. But I’m not sure how to edit dir-locals to set fill-column using a hook or minor mode.

Kludge from my personal config reproduced below¹, if it can help.  It
adds a function to git-commit-setup-hook that sets fill-column when it
detects that one of the remotes is Emacs's Savannah repo.

Thinking more about it, and considering the existence of the
git-commit-major-mode variable, I guess one could also

1) define a major mode derived from text-mode in their personal config;
2) add a .dir-locals-2.el file to their Emacs checkout that sets
git-commit-major-mode to that-new-mode, and fill-column to
  *checks config*
63
  *checks discussion*
^W64
  *ponders git-blaming to see what Past Self has to say for himself*
  *looks at the time*
  *you're off the hook, Past Self*
for that-new-mode.

Thinking *more* about it, setting git-commit-major-mode to log-edit-mode
in .dir-locals-2.el sounds like TRT in theory; in practice though I bet
it would lead to "interesting" fireworks².


¹

```
(defun my/git-upstreams ()
  ;; TODO: memoize, perhaps?
  (seq-uniq
   (seq-keep
    (lambda (remote-desc)
      (and (string-match "\\`.*\t\\(.*\\) (fetch)\\'" remote-desc)
           (match-string 1 remote-desc)))
    (process-lines "git" "remote" "-v"))))

(defun my/emacs-repo-p (upstreams)
  "Guess whether we are working in the Emacs repository.
UPSTREAMS is a list of fetch URLs."
  (member "https://git.savannah.gnu.org/git/emacs.git" upstreams))

(defvar my/git-commit-fill-columns
  '((my/emacs-repo-p . 63)))

(cl-defun my/git-commit-maybe-set-fill-column ()
  (let ((remotes (my/git-upstreams)))
    (pcase-dolist (`(,pred . ,column) my/git-commit-fill-columns)
      (when (funcall pred remotes)
        (cl-return-from my/git-commit-maybe-set-fill-column
          (setq fill-column column))))))

(add-hook
 'git-commit-setup-hook
 'my/git-commit-maybe-set-fill-column)
```

² Off the top of my head:

* bindings conflicting, e.g. log-edit-done vs with-editor-finish:
guessing the minor mode wins in that case… 🫣

* log-edit-generate-changelog-from-diff being ineffectual because
log-edit-diff-function is not set up: something to kludge around, though
Magit does also provide magit-commit-add-log from the diff buffer 🤷

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Robert Pluim]

>>>>> On Sun, 22 Sep 2024 23:23:06 +0200, Kévin Le Gouguec <kevin.legouguec@gmail.com> said:

    Kévin> * bindings conflicting, e.g. log-edit-done vs with-editor-finish:
    Kévin> guessing the minor mode wins in that case… 🫣

    Kévin> * log-edit-generate-changelog-from-diff being ineffectual because
    Kévin> log-edit-diff-function is not set up: something to kludge around, though
    Kévin> Magit does also provide magit-commit-add-log from the diff buffer 🤷

I set the fill-column to 64 from git-commit-setup-hook, and also have
it run 'magit-generate-changelog', which works from the commit buffer.

Robert
-- 

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: Po Lu <luangruo@yahoo.com>,  Stefan Kangas <stefankangas@gmail.com>,
>  emacs-devel@gnu.org
> Date: Sun, 22 Sep 2024 23:23:06 +0200
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
> > I took a look and it’s set for log-edit-mode only. It would be nice if magit can pick it up. I’m sure a lot of people (me included) use magit for developing Emacs. The only problem is magit’s commit message editing buffer doesn’t have a special major mode. It does git-commit-mode which is a minor mode, and runs git-commit-setup-hook. But I’m not sure how to edit dir-locals to set fill-column using a hook or minor mode.
> 
> Kludge from my personal config reproduced below¹, if it can help.  It
> adds a function to git-commit-setup-hook that sets fill-column when it
> detects that one of the remotes is Emacs's Savannah repo.
> 
> Thinking more about it, and considering the existence of the
> git-commit-major-mode variable, I guess one could also
> 
> 1) define a major mode derived from text-mode in their personal config;
> 2) add a .dir-locals-2.el file to their Emacs checkout that sets
> git-commit-major-mode to that-new-mode, and fill-column to
>   *checks config*
> 63
>   *checks discussion*
> ^W64
>   *ponders git-blaming to see what Past Self has to say for himself*
>   *looks at the time*
>   *you're off the hook, Past Self*
> for that-new-mode.

Isn't it a bug in magit that it doesn't do something like that
already?  Fill column is just the tip of an iceberg, because a log
message is generally human-readable text, and so should benefit from
other features of Text mode and its descendants, like spell-checking
etc.

Perhaps magit should simply use log-edit-mode?

Should we perhaps submit a feature request to the magit developers?

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
>> Cc: Po Lu <luangruo@yahoo.com>,  Stefan Kangas <stefankangas@gmail.com>,
>>  emacs-devel@gnu.org
>> Date: Sun, 22 Sep 2024 23:23:06 +0200
>> 
>> Yuan Fu <casouri@gmail.com> writes:
>> 
>> > I took a look and it’s set for log-edit-mode only. It would be nice if magit can pick it up. I’m sure a lot of people (me included) use magit for developing Emacs. The only problem is magit’s commit message editing buffer doesn’t have a special major mode. It does git-commit-mode which is a minor mode, and runs git-commit-setup-hook. But I’m not sure how to edit dir-locals to set fill-column using a hook or minor mode.
>> 
>> Kludge from my personal config reproduced below¹, if it can help.  It
>> adds a function to git-commit-setup-hook that sets fill-column when it
>> detects that one of the remotes is Emacs's Savannah repo.
>> 
>> Thinking more about it, and considering the existence of the
>> git-commit-major-mode variable, I guess one could also
>> 
>> 1) define a major mode derived from text-mode in their personal config;
>> 2) add a .dir-locals-2.el file to their Emacs checkout that sets
>> git-commit-major-mode to that-new-mode, and fill-column to
>>   *checks config*
>> 63
>>   *checks discussion*
>> ^W64
>>   *ponders git-blaming to see what Past Self has to say for himself*
>>   *looks at the time*
>>   *you're off the hook, Past Self*
>> for that-new-mode.
>
> Isn't it a bug in magit that it doesn't do something like that
> already?  Fill column is just the tip of an iceberg, because a log
> message is generally human-readable text, and so should benefit from
> other features of Text mode and its descendants, like spell-checking
> etc.

It does try to do "something like that"; AFAIU the two main knobs are:

* git-commit-major-mode lets users pick their preferred text-adjacent
major mode (or it lets maintainers choose it, e.g. setting that variable
in a checked-in .dir-locals.el; the default is text-mode),

* git-commit-setup-hook lets users turn on useful log-editing features;
the defcustom includes various opt-in functions.  Robert mentioned
magit-generate-changelog; there's also git-commit-turn-on-flyspell and
bug-reference-mode.

(There's also a mysterious git-commit-setup-changelog-support that
checks for

  (fboundp 'log-indent-fill-entry) ; New in Emacs 27

but I can't find any trace of log-indent-fill-entry in the tree so not
sure what that's about)

So what's "missing" from Magit's git-commit.el is a knob dedicated to
the fill-column for commit messages.  Quotes around "missing" because a
dedicated git-commit-fill-column defcustom used to exist, but was
eventually removed:

    <https://github.com/magit/magit/issues/2848>

(My takeaway skimming that thread: fill-column ought be enough)

> Perhaps magit should simply use log-edit-mode?
>
> Should we perhaps submit a feature request to the magit developers?

Maybe, though if core contributors are already using Magit and the only
"clue" is the occasional mis-filled changelog, perhaps the status quo is
not so bad, if we have a reliable answer to that problem.

(I realize my previous message might have made it look inordinately hard
to make git-commit do TRT for Emacs changelogs, but TBH a good chunk of
that message was theory-crafting, and another chunk was my convoluted
personal config; I think Robert's answer shows things can be simpler)

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Eli Zaretskii]

> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
> Cc: casouri@gmail.com,  luangruo@yahoo.com,  stefankangas@gmail.com,
>   emacs-devel@gnu.org
> Date: Mon, 23 Sep 2024 19:24:45 +0200
> 
> > Isn't it a bug in magit that it doesn't do something like that
> > already?  Fill column is just the tip of an iceberg, because a log
> > message is generally human-readable text, and so should benefit from
> > other features of Text mode and its descendants, like spell-checking
> > etc.
> 
> It does try to do "something like that"; AFAIU the two main knobs are:
> 
> * git-commit-major-mode lets users pick their preferred text-adjacent
> major mode (or it lets maintainers choose it, e.g. setting that variable
> in a checked-in .dir-locals.el; the default is text-mode),
> 
> * git-commit-setup-hook lets users turn on useful log-editing features;
> the defcustom includes various opt-in functions.  Robert mentioned
> magit-generate-changelog; there's also git-commit-turn-on-flyspell and
> bug-reference-mode.
> 
> (There's also a mysterious git-commit-setup-changelog-support that
> checks for
> 
>   (fboundp 'log-indent-fill-entry) ; New in Emacs 27
> 
> but I can't find any trace of log-indent-fill-entry in the tree so not
> sure what that's about)

That sounds to me like a heap of patches when just having a full-blown
mode like VC does would have done the job cleanly and seamlessly.

> So what's "missing" from Magit's git-commit.el is a knob dedicated to
> the fill-column for commit messages.

I'm quite sure that soon enough someone will come with more "missing"
stuff.  I still think they should use something very similar to
log-edit-mode there.  It doesn't make much sense not to.  E.g., the
.dir-locals settings would have been in effect for magit users as
well.

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Kévin Le Gouguec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
>> Cc: casouri@gmail.com,  luangruo@yahoo.com,  stefankangas@gmail.com,
>>   emacs-devel@gnu.org
>> Date: Mon, 23 Sep 2024 19:24:45 +0200
>> 
>> > Isn't it a bug in magit that it doesn't do something like that
>> > already?  Fill column is just the tip of an iceberg, because a log
>> > message is generally human-readable text, and so should benefit from
>> > other features of Text mode and its descendants, like spell-checking
>> > etc.
>> 
>> It does try to do "something like that"; AFAIU the two main knobs are:
>> 
>> * git-commit-major-mode lets users pick their preferred text-adjacent
>> major mode (or it lets maintainers choose it, e.g. setting that variable
>> in a checked-in .dir-locals.el; the default is text-mode),
>> 
>> * git-commit-setup-hook lets users turn on useful log-editing features;
>> the defcustom includes various opt-in functions.  Robert mentioned
>> magit-generate-changelog; there's also git-commit-turn-on-flyspell and
>> bug-reference-mode.
>> 
>> (There's also a mysterious git-commit-setup-changelog-support that
>> checks for
>> 
>>   (fboundp 'log-indent-fill-entry) ; New in Emacs 27
>> 
>> but I can't find any trace of log-indent-fill-entry in the tree so not
>> sure what that's about)
>
> That sounds to me like a heap of patches when just having a full-blown
> mode like VC does would have done the job cleanly and seamlessly.

That's how it was 10 years ago: there was a single major mode,
git-commit-mode, which "did it all" (setup emacsclient as git's EDITOR,
setup font-lock, provide key bindings, etc).  Then the decision was
taken to move to configurable-major-mode-plus-hook.

The commit log for that change¹ focuses on the technical details over
the motivation, but looking at the current defcustom's selection of
major modes, I guess the use-case is obvious - let people pick their
preferred markup for authoring messages, and tuck all the "VC-specific
extra features" under a dedicated minor mode & hook.

>> So what's "missing" from Magit's git-commit.el is a knob dedicated to
>> the fill-column for commit messages.
>
> I'm quite sure that soon enough someone will come with more "missing"
> stuff.  I still think they should use something very similar to
> log-edit-mode there.  It doesn't make much sense not to.  E.g., the
> .dir-locals settings would have been in effect for magit users as
> well.

Right.  And in principle users should be able to opt-in to log-edit-mode
(or vc-git-log-edit-mode?) by configuring git-commit-major-mode.

I just don't expect that to be seamless - because (AFAIR; apologies for
inaccuracies) log-edit-mode depends on callbacks set by vc-$BACKEND.el,
which in turn depend on bookkeeping usually managed by vc.el commands;
Magit steers mostly clear of that bookkeeping.

tl;dr I don't disagree but I don't see log-edit-mode integration into
Magit to be the path of least resistance.

(That shouldn't stop anyone from trying though, or submit a feature
request; this is all just my 2¢ as a {heavy Magit,occasional VC} user)


¹ 2014-03-18 "git-commit: allow use of arbitrary major mode" (feb58998)
  https://github.com/magit/magit/commit/feb58998fc128824728959695a9448e7752c2ca3.patch

Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)

[Yuan Fu]

> On Sep 24, 2024, at 12:10 AM, Kévin Le Gouguec <kevin.legouguec@gmail.com> wrote:
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
>>> Cc: casouri@gmail.com,  luangruo@yahoo.com,  stefankangas@gmail.com,
>>>  emacs-devel@gnu.org
>>> Date: Mon, 23 Sep 2024 19:24:45 +0200
>>> 
>>>> Isn't it a bug in magit that it doesn't do something like that
>>>> already?  Fill column is just the tip of an iceberg, because a log
>>>> message is generally human-readable text, and so should benefit from
>>>> other features of Text mode and its descendants, like spell-checking
>>>> etc.
>>> 
>>> It does try to do "something like that"; AFAIU the two main knobs are:
>>> 
>>> * git-commit-major-mode lets users pick their preferred text-adjacent
>>> major mode (or it lets maintainers choose it, e.g. setting that variable
>>> in a checked-in .dir-locals.el; the default is text-mode),
>>> 
>>> * git-commit-setup-hook lets users turn on useful log-editing features;
>>> the defcustom includes various opt-in functions.  Robert mentioned
>>> magit-generate-changelog; there's also git-commit-turn-on-flyspell and
>>> bug-reference-mode.
>>> 
>>> (There's also a mysterious git-commit-setup-changelog-support that
>>> checks for
>>> 
>>>  (fboundp 'log-indent-fill-entry) ; New in Emacs 27
>>> 
>>> but I can't find any trace of log-indent-fill-entry in the tree so not
>>> sure what that's about)
>> 
>> That sounds to me like a heap of patches when just having a full-blown
>> mode like VC does would have done the job cleanly and seamlessly.
> 
> That's how it was 10 years ago: there was a single major mode,
> git-commit-mode, which "did it all" (setup emacsclient as git's EDITOR,
> setup font-lock, provide key bindings, etc).  Then the decision was
> taken to move to configurable-major-mode-plus-hook.
> 
> The commit log for that change¹ focuses on the technical details over
> the motivation, but looking at the current defcustom's selection of
> major modes, I guess the use-case is obvious - let people pick their
> preferred markup for authoring messages, and tuck all the "VC-specific
> extra features" under a dedicated minor mode & hook.
> 
>>> So what's "missing" from Magit's git-commit.el is a knob dedicated to
>>> the fill-column for commit messages.
>> 
>> I'm quite sure that soon enough someone will come with more "missing"
>> stuff.  I still think they should use something very similar to
>> log-edit-mode there.  It doesn't make much sense not to.  E.g., the
>> .dir-locals settings would have been in effect for magit users as
>> well.
> 
> Right.  And in principle users should be able to opt-in to log-edit-mode
> (or vc-git-log-edit-mode?) by configuring git-commit-major-mode.
> 
> I just don't expect that to be seamless - because (AFAIR; apologies for
> inaccuracies) log-edit-mode depends on callbacks set by vc-$BACKEND.el,
> which in turn depend on bookkeeping usually managed by vc.el commands;
> Magit steers mostly clear of that bookkeeping.
> 
> tl;dr I don't disagree but I don't see log-edit-mode integration into
> Magit to be the path of least resistance.
> 
> (That shouldn't stop anyone from trying though, or submit a feature
> request; this is all just my 2¢ as a {heavy Magit,occasional VC} user)
> 
> 
> ¹ 2014-03-18 "git-commit: allow use of arbitrary major mode" (feb58998)
>  https://github.com/magit/magit/commit/feb58998fc128824728959695a9448e7752c2ca3.patch

I was hoping for some config that we can put in .dir-locals.el that works automatically for magit. That should prevent a lot of future corrections on fill column.  That doesn’t seem trivial, so I guess I’ll just stick something into my config and call it a day :-)

Yuan