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

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

[Stefan Kangas]

Po Lu via Mailing list for Emacs changes <emacs-diffs@gnu.org> writes:

>     ; .dir-locals.el (log-edit-mode) <fill-column>: Set to 64.
> ---
>  .dir-locals.el | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/.dir-locals.el b/.dir-locals.el
> index 1f08c882e0b..89fb76a55f3 100644
> --- a/.dir-locals.el
> +++ b/.dir-locals.el
> @@ -32,7 +32,8 @@
>                 (mode . bug-reference-prog)))
>   (log-edit-mode . ((log-edit-font-lock-gnu-style . t)
>                     (log-edit-setup-add-author . t)
> -		   (vc-git-log-edit-summary-target-len . 50)))
> +		   (vc-git-log-edit-summary-target-len . 50)
> +                   (fill-column . 64)))
>   (change-log-mode . ((add-log-time-zone-rule . t)
>  		     (fill-column . 74)
>  		     (mode . bug-reference)))

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.

I think we should revert this change, leaving `fill-column' in
`log-edit' at the value it was at.

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

[Po Lu]

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

or any of the old hand-written ChangeLog files.

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.

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

[Po Lu]

Jim Porter <jporterbugs@gmail.com> writes:

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

In the other thread, Eli stated that the correct fill-column is 65,
which is equivalent to 64 in log-edit-mode.

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

True, but the definitive setting lies elsewhere, in `add-log.el':

  (setq left-margin 8
	fill-column 74
	indent-tabs-mode t
	tab-width 8
	show-trailing-whitespace t)

which has existed since the beginning of time, or thereabouts.

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

We wish to limit ChangeLog entries to _74_ columns, while leaving the
door open to exceeding that limit for messages that are impossible to
fill neatly within it.

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

commit-msg is fine as-is, but CONTRIBUTE should be fixed.

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

[Jim Porter]

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

On 2/7/2024 7:34 PM, Po Lu wrote:
> Jim Porter <jporterbugs@gmail.com> writes:
> 
>> 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.
> 
> commit-msg is fine as-is, but CONTRIBUTE should be fixed.

I think I understand now. I find the CONTRIBUTE explanation rather 
confusing to be honest, since it introduces ChangeLog files, mentions 
ChangeLog entries in that context (which I interpret as "one commit 
message -> one ChangeLog entry"), and then later talks about ChangeLog 
entries again, but in the context of the commit message (where I 
interpret it to mean "one ChangeLog entry = one file/function changed"). 
Only after reading this a few times in detail did I notice this distinction.

I've attached a patch with a proposed change in that section (I'll defer 
to others on fixing the numeric values as needed) that I feel is 
clearer. In particular, I merged two paragraphs that described when to 
add a descriptive paragraph to the commit message, and I used "file 
entry" to talk about what the previous version called "ChangeLog 
entries" in the second sense I mentioned above.

No worries if this doesn't get merged, or if people change my wording. I 
just thought it would be helpful to show an example of what I'd find 
clearer.

[-- Attachment #2: 0001-CONTRIBUTE-Commit-messages-Improve-wording-about-fil.patch --]
[-- Type: text/plain, Size: 2767 bytes --]

From 51a7341b43460ca1a036411103a10a66e79e9e73 Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Wed, 7 Feb 2024 22:08:08 -0800
Subject: [PATCH] * CONTRIBUTE (Commit messages): Improve wording about file
 entries.

---
 CONTRIBUTE | 29 +++++++++++++++--------------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/CONTRIBUTE b/CONTRIBUTE
index 70b9760bb99..c942bfb3b8b 100644
--- a/CONTRIBUTE
+++ b/CONTRIBUTE
@@ -200,15 +200,21 @@ them right the first time, so here are guidelines for formatting them:
 
 - After the summary line, there should be an empty line.
 
-- Unindented ChangeLog entries normally come next.  However, if the
-  commit couldn't be properly summarized in the brief summary line,
-  you can put a paragraph (after the empty line and before the
-  individual ChangeLog entries) that further describes the commit.
-
-- 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.
+- If necessary, a paragraph describing the commit in more detail comes
+  next.  Explaining the rationale for a design choice is best done in
+  comments in the source code.  However, sometimes it is useful to
+  describe just the rationale for a change; that can be done in this
+  paragraph.  If you include this paragraph, there should be another
+  empty line after it.
+
+- File entries come next.  These begin with a "* " followed by the
+  file's name, the function or section that was changed in parentheses,
+  a ": ", and then a short description of the change.
+
+- Lines in the detailed paragraph and file 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.
 
 - If only a single file is changed, the summary line can be the normal
   file first line (starting with the asterisk).  Then there is no
@@ -240,11 +246,6 @@ them right the first time, so here are guidelines for formatting them:
 - Any lines of the commit message that start with "; " are omitted
   from the generated ChangeLog.
 
-- Explaining the rationale for a design choice is best done in comments
-  in the source code.  However, sometimes it is useful to describe just
-  the rationale for a change; that can be done in the commit message
-  between the summary line and the file entries.
-
 - Emacs generally follows the GNU coding standards for ChangeLogs: see
   https://www.gnu.org/prep/standards/html_node/Change-Logs.html
   or run 'info "(standards)Change Logs"'.  One exception is that
-- 
2.25.1

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

[Eli Zaretskii]

> Date: Wed, 7 Feb 2024 19:10:14 -0800
> Cc: emacs-devel@gnu.org, eliz@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> >  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.

The text is about ChangeLog-style entries in the commit log messages.

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

[Eli Zaretskii]

> Date: Wed, 7 Feb 2024 22:13:01 -0800
> Cc: Stefan Kangas <stefankangas@gmail.com>, emacs-devel@gnu.org, eliz@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 2/7/2024 7:34 PM, Po Lu wrote:
> > Jim Porter <jporterbugs@gmail.com> writes:
> > 
> >> 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.
> > 
> > commit-msg is fine as-is, but CONTRIBUTE should be fixed.

I'm not sure I understand what needs to be fixed in CONTRIBUTE.  If
that's fallout of the recent change of fill-column, then I'd expect
the author of that change to adjust CONTRIBUTE as needed.

> I think I understand now. I find the CONTRIBUTE explanation rather 
> confusing to be honest, since it introduces ChangeLog files, mentions 
> ChangeLog entries in that context (which I interpret as "one commit 
> message -> one ChangeLog entry"), and then later talks about ChangeLog 
> entries again, but in the context of the commit message (where I 
> interpret it to mean "one ChangeLog entry = one file/function changed"). 
> Only after reading this a few times in detail did I notice this distinction.

Please try to tell in more detail what confused you.  I don't want to
make any significant change in CONTRIBUTE, since the current text is
the result of many people reading it and commenting on its text.  So
I'd prefer to make the minimal required changes, not rewrite whole
passages anew.

AFAICS, the current text clearly explains what it means by "ChangeLog
entries" that are part of the commit log messages.  All of this text
is under the "Commit messages" heading, so it is all about commit log
messages, not about ChangeLog files (which we no longer maintain by
hand as part of documenting changes we install).  So I don't quite see
why you got confused by the text there; please elaborate.

> No worries if this doesn't get merged, or if people change my wording. I 
> just thought it would be helpful to show an example of what I'd find 
> clearer.

I'd prefer if you explained what is not clear in the current text.

Thanks.

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

[Jim Porter]

On 2/7/2024 11:23 PM, Eli Zaretskii wrote:
> Please try to tell in more detail what confused you.  I don't want to
> make any significant change in CONTRIBUTE, since the current text is
> the result of many people reading it and commenting on its text.  So
> I'd prefer to make the minimal required changes, not rewrite whole
> passages anew.

Sure thing. As I read it, the "Commit messages" section uses the phrase 
"ChangeLog entries" in two different senses. First is this passage:

> Ordinarily, a change you commit should contain a log entry in its
> commit message and should not touch the repository's ChangeLog files.
[...]
> Occasionally, commit messages are collected and prepended to a
> ChangeLog file, where they can be corrected.
[...]
>   If the summary line starts with a semicolon and a space "; ", the
>   commit message will be ignored when generating the ChangeLog file.
>   Use this for minor commits that do not need separate ChangeLog
>   entries, such as changes in etc/NEWS.

With the first and last sentences, I think this means that one commit 
message will become one ChangeLog entry. (Here, I'm mainly concerned 
with the terminology, since I know roughly what happens in the code.) 
That's consistent with the GNU Change Log manual[1], which describes it 
as, "an individual change or the smallest batch of changes that belong 
together".

Later, in the section about how to format a commit message is this:

> - Unindented ChangeLog entries normally come next.  However, if the
>   commit couldn't be properly summarized in the brief summary line,
>   you can put a paragraph (after the empty line and before the
>   individual ChangeLog entries) that further describes the commit.

This, and other bullet points are all talking in the context of a single 
commit. But this paragraph talks about multiple ChangeLog entries within 
one commit (*after* the summary line and descriptive paragraph). After 
carefully reading this, I think it means that one ChangeLog entry is a 
line of the form "* some/file.el (function): Frobnicate the widget." 
That's not consistent with the above, IMO.

After this paragraph is where I finally got things mixed up in the 
current discussion: "Lines in ChangeLog entries should preferably be not 
longer than 63 characters..." This again says "ChangeLog entries", and I 
initially read that in the first sense: "the ChangeLog entry is the 
commit message that's been inserted into the ChangeLog file". Since 
those messages are ultimately indented by one tab, that would affect how 
many columns you can fill to within the (raw, unindented) commit 
message. Whether you should count that tab is what ultimately confused me.

(When carefully re-reading this paragraph, I think it means that each 
ChangeLog entry is a single file/function change description, not the 
whole message.)

There are a couple of other cases where the terminology seems 
inconsistent to me:

> - If only a single file is changed, the summary line can be the normal
>   file first line (starting with the asterisk).

Here, the documentation talks about the "file first line", but that 
sounds like the same text that the paragraph about "Unindented ChangeLog 
entries" refers to.

> - Explaining the rationale for a design choice is best done in comments
>   in the source code.  However, sometimes it is useful to describe just
>   the rationale for a change; that can be done in the commit message
>   between the summary line and the file entries.

Here again, now the documentation calls these file/function change 
descriptions "file entries". (It's also talking about the reasoning for 
adding a descriptive paragraph, which I think would be helpful up above 
when it's originally mentioned.)

In conclusion, it seems to me that "ChangeLog entry" can mean two 
different things depending on what part you're reading, and we're not 
using a consistent name for the lines like "* some/file.el (function): 
Frobnicate the widget." How about calling those lines "file entries" 
everywhere?

[1]: 
https://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html#Change-Log-Concepts

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

[Eli Zaretskii]

> Date: Thu, 8 Feb 2024 09:49:41 -0800
> Cc: luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 2/7/2024 11:23 PM, Eli Zaretskii wrote:
> > Please try to tell in more detail what confused you.  I don't want to
> > make any significant change in CONTRIBUTE, since the current text is
> > the result of many people reading it and commenting on its text.  So
> > I'd prefer to make the minimal required changes, not rewrite whole
> > passages anew.
> 
> Sure thing. As I read it, the "Commit messages" section uses the phrase 
> "ChangeLog entries" in two different senses. First is this passage:
> 
> > Ordinarily, a change you commit should contain a log entry in its
> > commit message and should not touch the repository's ChangeLog files.
> [...]
> > Occasionally, commit messages are collected and prepended to a
> > ChangeLog file, where they can be corrected.

These talk about "ChangeLog files", not "ChangeLog entries".  So they
are about a different aspect.

> >   If the summary line starts with a semicolon and a space "; ", the
> >   commit message will be ignored when generating the ChangeLog file.
> >   Use this for minor commits that do not need separate ChangeLog
> >   entries, such as changes in etc/NEWS.

This indeed talks about "ChangeLog entries", and correctly so.

> With the first and last sentences, I think this means that one commit 
> message will become one ChangeLog entry.

There's nothing in the text which says that.  (Not that I think it's
important, since the text always talks about "entries", plural, and
never in singular, so whether it's a single file or several doesn't
seem to matter, for the purposes of what this text attempts to convey
and explain.)

> (Here, I'm mainly concerned with the terminology, since I know
> roughly what happens in the code.)  That's consistent with the GNU
> Change Log manual[1], which describes it as, "an individual change
> or the smallest batch of changes that belong together".

The language of the GNU manual is not relevant here, since this text
is not about ChangeLog files.

> Later, in the section about how to format a commit message is this:
> 
> > - Unindented ChangeLog entries normally come next.  However, if the
> >   commit couldn't be properly summarized in the brief summary line,
> >   you can put a paragraph (after the empty line and before the
> >   individual ChangeLog entries) that further describes the commit.
> 
> This, and other bullet points are all talking in the context of a single 
> commit. But this paragraph talks about multiple ChangeLog entries within 
> one commit (*after* the summary line and descriptive paragraph). After 
> carefully reading this, I think it means that one ChangeLog entry is a 
> line of the form "* some/file.el (function): Frobnicate the widget." 

Yes.  But where did you see any verbiage to the contrary?

> That's not consistent with the above, IMO.

I fail to see how it could be inconsistent, FWIW.

> After this paragraph is where I finally got things mixed up in the 
> current discussion: "Lines in ChangeLog entries should preferably be not 
> longer than 63 characters..." This again says "ChangeLog entries", and I 
> initially read that in the first sense: "the ChangeLog entry is the 
> commit message that's been inserted into the ChangeLog file". Since 
> those messages are ultimately indented by one tab, that would affect how 
> many columns you can fill to within the (raw, unindented) commit 
> message. Whether you should count that tab is what ultimately confused me.
> 
> (When carefully re-reading this paragraph, I think it means that each 
> ChangeLog entry is a single file/function change description, not the 
> whole message.)
> 
> There are a couple of other cases where the terminology seems 
> inconsistent to me:
> 
> > - If only a single file is changed, the summary line can be the normal
> >   file first line (starting with the asterisk).
> 
> Here, the documentation talks about the "file first line", but that 
> sounds like the same text that the paragraph about "Unindented ChangeLog 
> entries" refers to.

My conclusion from this is that we should simply use "ChangeLog
entries" everywhere where we mean it.  So I've now changed CONTRIBUTE
to use that consistently, avoiding alternative equivalent terminology
that succeeded to confuse you.

> In conclusion, it seems to me that "ChangeLog entry" can mean two 
> different things depending on what part you're reading, and we're not 
> using a consistent name for the lines like "* some/file.el (function): 
> Frobnicate the widget." How about calling those lines "file entries" 
> everywhere?

I prefer to call them "ChangeLog entries", since that's what we were
using, by and large, with a small number of exceptions, which are now
gone.

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

[Jim Porter]

On 2/8/2024 11:30 AM, Eli Zaretskii wrote:
>> Date: Thu, 8 Feb 2024 09:49:41 -0800
>> Cc: luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>>
>>> - Unindented ChangeLog entries normally come next.  However, if the
>>>    commit couldn't be properly summarized in the brief summary line,
>>>    you can put a paragraph (after the empty line and before the
>>>    individual ChangeLog entries) that further describes the commit.
>>
>> This, and other bullet points are all talking in the context of a single
>> commit. But this paragraph talks about multiple ChangeLog entries within
>> one commit (*after* the summary line and descriptive paragraph). After
>> carefully reading this, I think it means that one ChangeLog entry is a
>> line of the form "* some/file.el (function): Frobnicate the widget."
> 
> Yes.  But where did you see any verbiage to the contrary?

The first sentence of the section begins, "Ordinarily, a change you 
commit should contain a log entry in its commit message...". That is, 
there's just one log entry in the commit message. Here, it mentions 
multiple entries in a single commit.

In practice, I think this section of CONTRIBUTE is clear enough for 
people to understand how to properly-format their commit messages, and 
my main confusion was in whether to account for TAB characters in the 
ChangeLog *files* when counting columns for wrapping.

I'm still not sure I could define a "ChangeLog entry" (as used here) 
precisely enough to use the term when creating a hypothetical formal 
grammar for the format, but that's probably of little practical use, and 
our time would be better spent elsewhere.

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

[Eli Zaretskii]

> Date: Thu, 8 Feb 2024 12:21:37 -0800
> Cc: luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> >> This, and other bullet points are all talking in the context of a single
> >> commit. But this paragraph talks about multiple ChangeLog entries within
> >> one commit (*after* the summary line and descriptive paragraph). After
> >> carefully reading this, I think it means that one ChangeLog entry is a
> >> line of the form "* some/file.el (function): Frobnicate the widget."
> > 
> > Yes.  But where did you see any verbiage to the contrary?
> 
> The first sentence of the section begins, "Ordinarily, a change you 
> commit should contain a log entry in its commit message...". That is, 
> there's just one log entry in the commit message. Here, it mentions 
> multiple entries in a single commit.

So that single use of "entry" (not "ChangeLog entry", mind you) was
what confused you?  very well, now that single instance is gone as
well.

> In practice, I think this section of CONTRIBUTE is clear enough for 
> people to understand how to properly-format their commit messages, and 
> my main confusion was in whether to account for TAB characters in the 
> ChangeLog *files* when counting columns for wrapping.

The text talks about ChangeLog entries in a commit log message, and
explicitly says "unindented", so the answer is definitely NO.

Thanks.

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

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Jim Porter <jporterbugs@gmail.com> writes:
>
>> 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?
>
> In the other thread, Eli stated that the correct fill-column is 65,
> which is equivalent to 64 in log-edit-mode.

Are you saying that setting the fill-column to 64 makes it wrap text to
65 columns?

In `vc-git-log-edit-mode`, after `C-x f 10 RET`, the text

12345 7890
12345 78901

gets reflowed by M-q to

12345 7890
12345
78901

Isn't that what you would expect?  You get exactly 10 characters wide
text as a maximum.

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

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Are you saying that setting the fill-column to 64 makes it wrap text to
> 65 columns?

Yes, in defun lists themselves:

* test.el (abcdefghijklmnopqrstuvwxyz1234567890ABCDEFGHIJKLMNOP):

is not modified with fill-column set to 64, but:

* test.el (abcdefghijklmnopqrstuvwxyz1234567890ABCDEFGHIJKLMNOPQ):

is.  Intervening prose between defun lists is filled with the default
fill-region, which does not behave in this manner.