[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Whither changelogs
From: |
Keith Marshall |
Subject: |
Re: Whither changelogs |
Date: |
Thu, 7 Oct 2021 10:07:12 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.1 |
On 06/10/2021 15:03, G. Branden Robinson wrote:
> At 2021-10-05T08:56:24+0100, Keith Marshall wrote:
>> Why do you waste your time, indulging in such asinine whimsy? Why
>> introduce a commit which contributes absolutely zero value?
>
> I object to your characterization, but I do it because excessively long
> lines disrupt my workflow.
In ChangeLog, GNU convention is that lines wrap at *78* characters;
anything less is *incompatible* with *my* workflow, (and IMO, serves
only to introduce excessive ugliness).
>> The ChangeLog entry, which you modified, was already 100% compliant
>> with established GNU convention; I know this, because it was I who
>> wrote it.
>
>> I know that the lines were NOT excessively long, because I edited it in
>> vim, with the default filetype plug-in for changelog active; this
>> GUARANTEES that the lines are wrapped to a sane length (78 chars max),
>> which is consistent with GNU convention.
>
> Why is Vim, or this plugin you speak of, disregarding the modeline at
> the bottom of the file?
>
> ##### Editor settings
> ...
> vim:set autoindent textwidth=72:
Vim, (and its changelog filetype plug-in), are working fine; in *my*
workflow, they simply never see your aberrant mode-line:
vim <project.files> ...
hg qnew -m 'Summary line' <changeset.patch>
hg chlog -l1 > wip/Changelog
vim wip/ChangeLog
logmsg --full wip | hg qrefresh -l-
then, when I'm ready to finally commit, and push the patch, (assuming
that I've already moved it to first in the queue):
hg qpop 0
hg qchlog --rewrite `hg root`/ChangeLog
hg qrefresh
hg qfinish -a
hg push
(the 'logmsg' command, in the foregoing, comes from my own 'mingw-pkg'
suite: https://osdn.net/users/keith/pf/mingw.pkg/; it extracts content
from the topmost ChangeLog, in the nominated directory, and formats it
for incorporation within the patch header).
> "textwidth" is not a new feature; as best I can recall, it goes back to
> the 1990s. (Vim works for me, and "set colorcolumn=+1" in my
> $HOME/.vimrc makes overlong lines plainly visible.)
So, if you *must* have that mode-line in ChangeLog, (IMO, it doesn't
belong), then set textwidth to match established convention (i.e. 78);
that's what I've always used, throughout my association with groff, (and
AFAIK, Werner did too; he certainly never rejected, or rewrapped, any of
my submitted ChangeLog entries with textwidth=78).
78 characters is *not* over-long, for lines in ChangeLog; it is the
established convention, for every project with which I have been
involved, (and many with which I merely have a passing acquaintance).