groff
[Top][All Lists]
Advanced

[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: John Gardner
Subject: Re: groff man(7) `B` macro behavior with `\c`, and input traps
Date: Mon, 6 Jun 2022 21:14:01 +1000

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


I haven't read the entirety of this thread, but why hasn't the name *"command
suppressor"* or *"control suppressor"* been considered? AFAIK, \& has no
other uses outside of an input line (diversions notwithstanding), so naming
it *"input break"* is confusing at best.

Last year I was confused as to why this wasn't working:

.di FOO
\&.BAR
.br
.di
.if '\*[FOO]'.BAR' …

... and it eventually dawned on me that \& was preserved in the diversion,
as opposed to discarded after evaluation. Had the sequence been named *"input
break"* in the documentation, the thought of \& being an opaque character
might never have occurred to me.



On Mon, 6 Jun 2022 at 17:27, Ingo Schwarze <schwarze@usta.de> wrote:

> 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
> > CINCOMPAC
> > confirmed the ceasefire.
> >
> > You could equivalently write this.
> >
> > Today,
> > .B
> > .SM CINCOMPAC
> > 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
>   text
>
> sets "text" in Roman font but
>
>   .I arg\c
>   text
>
> 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
> https://cvsweb.bsd.lv/~checkout~/mandoc/TODO?rev=HEAD :
>
>   - 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
>
> Yours,
>   Ingo
>
>


reply via email to

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