groff
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]