Re: master 9ccaa09a635: ; .dir-locals.el (log-edit-mode) <fill-column>: Set to 64.

[Jim Porter]

On 2/7/2024 5:36 PM, Po Lu wrote:
> Stefan Kangas <stefankangas@gmail.com> writes:
>
> > This change breaks with our conventions and historical practice, and
> > makes both commit messages and ChangeLogs take up much more vertical
> > space for no practical benefit.
>
> ??? Our historical and current practice is to fill ChangeLogs to 74
> columns, which setting the fill-column in log messages to 64
> accomplishes.

Aren't the entries in ChangeLogs indented by one tab (so 8 characters by 
default), which would mean that if we want to fill the ChangeLog to 74 
columns, we actually want log-edit-mode to fill to 74 - 8 = 66 columns?

>  See CONTRIBUTE:
>
> - Lines in ChangeLog entries should preferably be not longer than 63
>    characters, and must not exceed 78 characters, unless they consist
>    of a single word of at most 140 characters; this 78/140 limit is
>    enforced by a commit hook.

That passage was last changed by Eli (CCed) in 2022 (commit 
161cb6034cec). Previously, it said this:

> - Limit lines in commit messages to 78 characters, unless they consist
>   of a single word of at most 140 characters; this is enforced by a
>   commit hook.

(There was a sentence after that recommending the first line be <=50 
columns moved elsewhere in 2021, but otherwise, that passage has been 
that way from 2015 until Eli's change.)

In any case, if the intent is really to limit *ChangeLog entries* to 
78/140 columns instead of *commit messages*, then the commit hook that 
CONTRIBUTE mentions is wrong; it checks for exceeding 78/140 columns in 
the commit message.

I don't have a terribly strong opinion here of what number to use, but 
we should at least resolve the inconsistencies in CONTRIBUTE, 
.dir-locals.el, and build-aux/git-hooks/commit-msg.