I'm not sure whether to stay quiet or point out that you may have misread

I'm referring to a select choice of words that just happens to neatly fall
against the 72-character limit... =) Here's the commit message I was
referring to:

Like man(7), mdoc(7) is a macro package for marking up computer manuals.
The main difference is that mdoc is semantic rather than presentational,
providing authors with a full DSL to abstract page markup from low-level
Roff commands. By contrast, `man` is minimalist and leaves formatting to
the author, who is expected to have a working amount of Roff knowledge.

Therefore the use of `mdoc` for marking up Node's manpage is a decidedly
better choice than bare `man`. Less room is left for error and mandoc(1)
offers very robust error-checking and linting.

I've been writing every commit-message like this for years and I got too
good at it, now I look completely mental... :-\

On 16 April 2018 at 23:56, Ralph Corderoy <ra...@inputplus.co.uk> wrote:

> Hi John,
> > Does anybody else here manage to line-wrap their commit messages at
> > *precisely* 72-characters without the aide of hyphenation or
> justification?
> > ;-) Or is it just me?
> I find myself sometimes breaking a line after a comma or full stop,
> without starting a new paragraph, if the line is still a good length.
> Rather than vim's `gwap', or fmt(1), say.
> It's convenient for later edits being isolated in their ripple effect.
> I think Bell Labs book authors often did this when using ed(1) as the
> edits were line based and the edit often wanted to work on a clause.
> Does anyone here know a fmt(1)-er that tries to do this?
> fmt(1) alternatives I know are
>     https://en.wikipedia.org/wiki/Par_(command)
>     http://search.cpan.org/~neilb/Text-Autoformat-1.74/lib/Text/
> Autoformat.pm
> The latter can easily be run from the command line,
> not just used as a module in Perl.
> --
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy

Reply via email to