...when rendering some man pages, such as those of ncurses.
I did not manage (nor seriously attempt) to identify the root cause of
this bug. ncurses's use of `SH` and `SS` man(7) macros is
unremarkable.[1] I cannot account for why the less(1) man page renders
fine and ncurses pages like insstr(3) do not. But render badly they do,
emitting *roff logic as formatted output.
```
$ 9 nroff -man $(man -w insstr) | grep -F .ss | cat -v
"'''if^GNAME^GSYNOPSIS^G .ss 18 NAME
"'''if^GSYNOPSIS^GSYNOPSIS^G .ss 18 SYNOPSIS
"'''if^GDESCRIPTION^GSYNOPSIS^G .ss 18 DESCRIPTION
"'''if^GRETURN^GSYNOPSIS^G .ss 18 RETURN VALUE
"'''if^GNOTES^GSYNOPSIS^G .ss 18 NOTES
"'''if^GEXTENSIONS^GSYNOPSIS^G .ss 18 EXTENSIONS
"'''if^GPORTABILITY^GSYNOPSIS^G .ss 18 PORTABILITY
"'''if^GHISTORY^GSYNOPSIS^G .ss 18 HISTORY
"'''if^GSEE^GSYNOPSIS^G .ss 18 SEE ALSO
```
With this patch:
```
$ 9 nroff -man $(man -w insstr) | grep -F .ss | cat -v | grep . || echo NO OUTPUT
NO OUTPUT
```
I do observe that the problem seems to correspond to the only use in the
package of the old-fashioned `'''` commenting convention _within a macro
definition_. I have a notion of how GNU troff works, but little about
AT&T troff. That said, if I were to try to get to the bottom of this
problem, I'd look into if and how the no-break command character is
handled differently in copy mode. I see nothing in CSTR #54 to suggest
that the command characters have different meanings in copy mode and its
complement.[2]
My solution is to use idiomatic comment syntax inside macro definitions.
[1] https://github.com/ThomasDickey/ncurses-snapshots/blob/d5dc8a4a7c15474652d73dee37d905c8205f6ab4/man/curs_insstr.3x#L47
[2] unnamed in AT&T documentation but which I term "interpretation mode"
in groff