Debian Bug report logs - #1036826
po4a: Escape sequence \c encountered. This is not completely handled yet.

Full log

Message #33 received at [email protected] (full text, mbox, reply):

Received: (at 1036826-submitter) by bugs.debian.org; 29 May 2023 20:17:41 +0000
From [email protected] Mon May 29 20:17:41 2023
X-Spam-Checker-Version: SpamAssassin 3.4.6-bugs.debian.org_2005_01_02
	(2021-04-09) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-5.1 required=4.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FOURLA,FREEMAIL_FROM,
	FVGT_m_MULTI_ODD,GENDER,MDO_CABLE_TV3,MURPHY_DRUGS_REL8,PGPSIGNATURE,
	RCVD_IN_DNSWL_NONE,REMOVEDOT,SPF_HELO_NONE,SPF_PASS,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no
	version=3.4.6-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 47; hammy, 149; neutral, 358; spammy,
	1. spammytokens:0.995-1--dwb hammytokens:0.000-+--H*ct:pgp-sha256,
	0.000-+--H*ct:application, 0.000-+--H*ct:protocol,
	0.000-+--H*ct:micalg, 0.000-+--H*ct:signed
Return-path: <[email protected]>
Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]:54358)
	by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128)
	(Exim 4.94.2)
	(envelope-from <[email protected]>)
	id 1q3jJF-00CZJ9-5N
	for [email protected]; Mon, 29 May 2023 20:17:41 +0000
Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-19f22575d89so1372055fac.0
        for <[email protected]>; Mon, 29 May 2023 13:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20221208; t=1685391457; x=1687983457;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
        bh=pvvTUlMMyUupo7KiLBTzckNSEAipum8q6+wQS+QTleA=;
        b=oSzdrKnkCOHSCF8lV5cMaQ1AoKPCmlC3Zm1Lpai08ErUOA7NVZvcRDNRZCON2PGztG
         ZlDU0SVLOMZghhhi4rodIiVW4BCygSEW4glOU+xeIkgVs8OcMxmHXZOEKD11mJCjH2oE
         yLW98fiTBLWsFEloej9W/DzCaSjPmhepbKjz69Ho35XGGyMh21X/oDOwYQp2RRMchM9N
         zZFsR4tJnVnF8ZFUfDQRwhtvd5B9VUa3Ocjvw6/2DLGfYsFxXot/+esPOASs3RkOQ/UC
         Jn25T53UQJE/mpXkDr5Abmp1SoAd9JQOuOieuW0VVVolBEzWEQhrRVDylVOhcdh5hO8I
         p3ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20221208; t=1685391457; x=1687983457;
        h=in-reply-to:content-disposition:mime-version:references:message-id
         :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=pvvTUlMMyUupo7KiLBTzckNSEAipum8q6+wQS+QTleA=;
        b=OGAxIJutnZsNY+9pqu8d2bWGwZWMYzQELeUSvbUdsDsLap5ums5aRBE1EHy56YR3An
         8yDGWDuwGcUWN29zwNOEPkcfOL322fO761ULOJ3mTSds9GcvkXUSYESOqq8Wo3NjdMlR
         bNphIqZdSudrvmqmYlL28rfBscxxDLLqezsqbkmxKMEPcXITzGilbbd1PyY/NqOUDNyX
         D91w3wCU/FK0QJkAkBBv1AaQS7KS1MwJgwzSz5wOX2un12yTvBujUPwxARenhooz9oLh
         wiqHkONcCQdDhvu5ZCAmnK3IUEPB0cpzMzUJQtCn+Zm7UgQsZyY7UEKSihA3TEpzWMze
         FmVQ==
X-Gm-Message-State: AC+VfDzmMI5RyxoEN3WACumEwfyFjCPa2DdRbldLJi7AFNqDl99izu0+
	4WO4tVlBE/2iCzHK/bZYYtQd6Gartnw=
X-Google-Smtp-Source: ACHHUZ4u/Bl12xTS3qTztkQ6w3yrGhBwjfEWp2YDUbRmVNwwVV5wz1ndAnIoj4+dmknU2V3aW6z/MA==
X-Received: by 2002:a05:6871:501:b0:19f:774a:60bb with SMTP id s1-20020a056871050100b0019f774a60bbmr1171029oal.43.1685391456588;
        Mon, 29 May 2023 13:17:36 -0700 (PDT)
Received: from illithid (ip68-12-97-90.ok.ok.cox.net. [68.12.97.90])
        by smtp.gmail.com with ESMTPSA id x20-20020a05687031d400b0017243edbe5bsm4944800oac.58.2023.05.29.13.17.36
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Mon, 29 May 2023 13:17:36 -0700 (PDT)
Date: Mon, 29 May 2023 15:17:34 -0500
From: "G. Branden Robinson" <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: How to avoid using '\c' in man pages
Message-ID: <20230529201734.smdccxbz2y5goadf@illithid>
References: <ZHT51KkGvqm5QZyy@localhost>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="zv2ffsd5dn56sqge"
Content-Disposition: inline
In-Reply-To: <ZHT51KkGvqm5QZyy@localhost>

[Message part 1 (text/plain, inline)]

[Debian BTS users: please CC the groff list on replies.]

At 2023-05-29T19:15:32+0000, Bjarni Ingi Gislason wrote:
>   For a background material see Debian bug #1036826 or
> the home page of "Bug Reports" in Debian for the package "po4a".

That background is pretty important, because nothing you said after that
point in the message made any sense to me.

So I'll quote Helge Kreutzmann's original bug report:

>> .TP
>> .BI \-f " program-file\fR,\fP "\c
>> .BI \-\^\-file " program-file"
>> Read the \*(AK program source from the file
>> 
>> The "\c" causes the following (fatal) warning, i.e. no output:
>> 
>> Escape sequence \c encountered. This is not completely handled yet.

It is important for programs that interpret man pages to handle this.
It should be given some priority.  But I wouldn't be surprised if one
reason it hasn't already been is that there has historically been a lot
of mystique and folkore around the meaning of this roff escape sequence.

Some quotes from groff_man_style(7) from the forthcoming groff 1.23.0
release (now at release candidate 4) might help.[1]

    .TP [indentation]
        Set a paragraph with a leading tag, and the remainder of the
        paragraph indented.  A one-line input trap is planted; text on
        the next line, which can be formatted with a macro, becomes the
        tag, which is placed at the current left margin.  The tag can be
        extended with the \c escape sequence.  Subsequent text is
        indented by indentation, if specified, and by a default amount
        otherwise; see subsection "Horizontal and vertical spacing"
        below.  If the tag is not as wide as the indentation, the
        paragraph starts on the same line as the tag, at the applicable
        indentation, and continues on the following lines.  Otherwise,
        the descriptive part of the paragraph begins on the line
        following the tag.
[...]
    groff's own command-line interface serves to illustrate most of the
    specimens of synopsis syntax one is likely to encounter.

        .SY groff
        .RB [ \-abcCeEgGijklNpRsStUVXzZ ]
        .RB [ \-d\~\c
        .IR cs ]
        .RB [ \-d\~\c
        .IB name =\c
        .IR string ]
        .RB [ \-D\~\c
        .IR enc ]
        (and so on similarly)
[...]
    Several features of the above example are of note.
[...]
    o The output line continuation escape sequence \c is used with font
      style alternation macros to allow all three font styles to be set
      without (breakable) space among them; see subsection "Portability"
      below.
[...]
    \c  End a text line without inserting space or attempting a break.
        Normally, if filling is enabled, the end of a text line is
        treated like a space; an output line may be broken there (if
        not, an adjustable space is inserted); if filling is disabled,
        the line will be broken there, as in .EX/.EE examples.  The next
        line is interpreted as usual and can include a macro call
        (contrast with \newline).  \c is useful when three font styles
        are needed in a single word, as in a command synopsis.

            .RB [ \-\-stylesheet=\c
            .IR name ]

        It also helps when changing font styles in .EX/.EE examples,
        since they are not filled.

            .EX
            $ \c
            .B groff \-T utf8 \-Z \c
            .I file \c
            .B | grotty \-i
            .EE

>> As a workaround I'm currently considering patching the source files
>> "on the fly" to get the build to proceed.
>> 
>> Until recently I was ignoring this message, because it implies that
>> just some detail is not properly handled; however I did not realize
>> that the build fails.

Now, quoting Bjarni's claims in the bug log, and adding in a bit more of
the original context...

> > .SH OPTIONS
> > .I Gawk
> > accepts the following options.
> > Standard options are listed first, followed by options for
> > .I gawk
> > extensions, listed alphabetically by short option.
> > .TP
> > .BI \-f " program-file\fR,\fP "\c
> > .BI \-\^\-file " program-file"
> > Read the AWK program source from the file
> > .IR program‐file ,
> This is a wrong use of '\c', as its purpose is to join the output of
> two macros _without_ an intervening space character.
>
>   So remove ' ' and '\c', changing
>
> .BI \-f " program-file\fR,\fP "\c
>
>   to
>
> .BI \-f " program-file\fR,\fP"

This is bad advice in a couple of respects.  Because you have only two
(space-separated) words before a break, there's no need for \c at all.

I would document the option as follows.

.TP
.BI \-f " program-file"
.TQ
.BI \-\-file " program-file"
Read the AWK program source from the file
.I program-file,

I made some other changes while I was at it.[2]

The other problem is that Bjarni's advice introduced a bunch of
superfluous italic correction escape sequences.  There is absolutely no
reason to do this when (1) you're abutting italic text with _space_ and
(2) you're using groff man(7)'s font alternation macros, which take care
of italic corrections _for_ you, as they are documented to do.

Quoting groff_man_style(7) again:

    Unlike the above font style macros, the font style alternation
    macros below set no input traps; they must be given arguments to
    have effect.  Italic corrections are applied as appropriate.  If a
    space is required within an argument, first consider whether the
    same result could be achieved with as much clarity by using single-
    style macros on separate input lines.  When it cannot, double-quote
    an argument containing embedded space characters.  Setting all three
    different styles within a word presents challenges; it is possible
    with the \c and/or \f escape sequences.  See subsection
    "Portability" below for approaches.

I'm attaching an abbreviated demonstration of my changes.  I tested it
with groff Git HEAD, groff 1.22.4, DWB 3.3 nroff, and Heirloom Doctools
nroff.

Bjarni, please do not offer yourself as an authority on correct man page
composition when you don't know what you're talking about and have filed
bug reports complaining of that fact.

https://savannah.gnu.org/bugs/?64238

Regards,
Branden

[1] https://mail.gnu.org/archive/html/groff/2023-04/msg00135.html

[2] I used groff man(7)'s permissively licensed `TQ` extension,[3] took
    out the hair space escape sequence, and switched from `IR` to `I`
    when setting a metasyntactic variable in running text with adjacent
    punctuation because it looks better when typeset.  But all of these
    are matters of taste, not correctness.

[3] The gawk(1) page author works around it by doing the `PD 0` push-pop
    trick with another `TP` call.  This is perfectly portable as far as
    I know, if mystifying to the novice man(7) author.  I find `TQ`
    cleaner.  I feel that `PD` tricks will be made unnecessary with some
    semantic/structural tagging reforms to man(7) I have in mind.

    https://lists.gnu.org/archive/html/groff/2022-12/msg00075.html
    https://lists.gnu.org/archive/html/groff/2022-12/msg00078.html

    But those will have to wait for groff 1.24...

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.