[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: groff man(7) `B` macro behavior with `\c`, and input traps

From: Ingo Schwarze
Subject: Re: groff man(7) `B` macro behavior with `\c`, and input traps
Date: Mon, 6 Jun 2022 09:18:01 +0200

Hi Branden,

G. Branden Robinson wrote on Sun, Jun 05, 2022 at 06:08:46PM -0500:

> [Warning: this message is long.]

Thanks for the thorough explanation.

> At 2022-06-05T19:09:53+0200, Ingo Schwarze wrote:

>> On a tangent, i just noticed that
>>   .TH TEST 1
>>   .B foo\c
>>   bar
>> prints "bar" in Roman font with mandoc(1), which seems correct to me,
>> whereas it appears to print "bar" in bold with groff-current
>> compiled from git, which seems strange to me, just as if i had
>> written
>>   .TH TEST 1
>>   .B foo\c
>>   .B bar
>> Which one is correct output, Roman bar or bold bar?

> I believe a bold "bar" is correct.  It is also consistent with Heirloom
> Doctools nroff, which I last built from its Git HEAD on 2020-02-25.
> (This is still fairly close to HEAD today.)
> Here is groff man(7)'s definition of the `B` macro from Git HEAD.
> groff 1.22.4's is not materially different.
> .\" Set arguments (or next input line if none) in bold style.
> .de1 B
> .  itc 1 an-input-trap

Ouch: .itc!

> .  ft B
> .  if \\n[.$] \&\\$*
> ..
> As to _why_ it works this way, here is an attempted explanation and
> defense thereof.

> .B
> .
> foo
> Should "foo" be in bold?

Yes, groff and mandoc output agree.

> So, what kind of line produces formatted output?  Well, text lines.

And to allude to an another conversation we are currently having,
including those that contain nothing but "\&", but *not* those
that are completely empty, which would make you think that "\&"
is a "zero-width non-breaking space" or a "zero-width non-printing
character" rather than merely an "input break".  But that should
really be decided in another thread.

> Today,
> .B
> .SM
> confirmed the ceasefire.
> You could equivalently write this.
> Today,
> .B
> confirmed the ceasefire.

Yes, both print CINCOMPAC in bold in both groff and mandoc,
even though mandoc fails to document that.

> .TP
> .BR \-f [\c
> .BI = cond\c
> ]
> This option frobnicates the boojum,
> under the condition
> .I cond,
> which may be
> .B florp
> or
> .BR snoggle .

Yes, indeed groff and mandoc format this the same way, ending the .TP
next line scope right before "This option".  In that sense, i understand
why .TP now uses .itc rather than .it.

> And that's the story of why groff and Heirloom Doctools nroff put "bar"
> in bold.

So since .B uses .itc, and that appears to match Heirloom behaviour
according to your research, it might be unwise to change that now.

Still, i wonder whether choosing that behaviour was a good decision.
>From the user perspective, this feel asymmetric, in particular for
users who dislike traps and don't want to think about them:

  .BI command arg\c

sets "text" in Roman font but

  .I arg\c

sets "text" in italics?  Isn't that really surprising from the
user perspective?  No argument about .TP, but wouldn't it have
been better for .B and .I to use .it rather than .itc for symmetry
with .BI?

For now, i have added this entry to :

  - the man(7) single-font macros (e.g. .B) use .itc,
    so ".B foo\c" followed by "bar" prints "bar" in bold
    gbranden@ Sun, 5 Jun 2022 18:08:46 -0500


reply via email to

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