Re: [PATCH] repair recent, ill-conceived man page changes

[Chet Ramey]

On 10/11/23 5:08 AM, G. Branden Robinson wrote:
> Hi Chet,
>
> Please consider reverting the following recent changes to the bash man
> page.  Bjarni should have run them by the groff list first, because some
> of them are ill-considered.

OK. I'm trying to understand them myself; please take my comments in that
spirit.


> +.\" suggested by Bjarni Ingi Gislason <bjarniig@simnet.is>
> +.if n \{\
> +.kern 0
> +.ss 12 0
> +.\}
>
> The above change is half pointless and half intrusive.
>
> A) No formatter for terminal output devices ("nroff mode", which is
>     tested by "if n" performs kerning.  So that's a no-op.
>
> B) The amount of intersentence spacing, for man pages, is matter of the
>     _reader's_ taste and should be left to them.  mandoc(1) ignores this
>     request and I'm glad it does.  So that, too, is a no-op with that
>     formatter.

Is his intent here to force French spacing instead of English spacing?
How does groff deal with input where the number of spaces after
a period varies? My personal writing style has changed from two spaces to
one over a number of years, and the man page reflects that.

> +.if t \{\
> +.lg 0
> + !    case    coproc    do    done    elif    else    esac    fi    for    
> function    if    in    select    then    until    while    {    }    time    
> [[    ]]
> +.lg 1
> +.\}
>
> This change is pointless because no ligatures are defined for any of the
> letter pairs in the text in any known formatter (the ligature for "ct",
> like that for "st" [not seen here] is archaic in English typography and
> seldom seen in digital fonts). 

I assume he was interested in what formatters do with the `fi'. I couldn't
see any discernable difference myself.


> @@ -11629,7 +11638,7 @@ .SH "SHELL COMPATIBILITY MODE"
>   .BR compat41 ,
>   and so on).
>   There is only one current
> -compatibility level -- each option is mutually exclusive.
> +compatibility level \(en each option is mutually exclusive.
>   The compatibility level is intended to allow users to select behavior
>   from previous versions that is incompatible with newer versions
>   while they migrate scripts to use current features and
>
> An en-dash is not the correct glyph: an em-dash is.  As it happens, the
> "en" special character identifier is less portable than "em" to boot.
> See section "History" of groff_char(7).

Thanks for the clarification.

> Authorities differ on whether space should surround em dashes; from what
> I have seen, a majority favor omitting them, and that is what I do in
> the groff man pages, but I cannot say it is more than a matter of taste.

I think it's cleaner with spaces, but it's clearly personal taste.


> Chet, I'm happy to prepare a patch reflecting the above recommendations
> (against the "devel" branch at git.sv.gnu.org:/srv/git/bash.git).  Let
> me know.

Thanks, I'll take care of it.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/