At 2026-05-11T09:56:39-0400, Chet Ramey wrote: > On 5/8/26 4:41 PM, G. Branden Robinson wrote: > > What do you think? If I build it, will you come? ;-) > > The Bash man page uses lists liberally. If there is a macro that makes > it easier and achieves consensus, I'd use it.
Glad to hear it! At 2026-05-11T10:25:16-0400, Chet Ramey wrote: > On 5/10/26 8:17 AM, G. Branden Robinson wrote: > > I need to check out a hard case like the Bash man page. > > It's probably hard because I'm willing to tinker until I get the > layout I want, which has led to some minor inconsistencies, I'm sure. This work is underway. https://lists.gnu.org/archive/html/groff-commit/2026-05/msg00101.html With this message I'll try to stop hitting the coreutils list and most people in the CC on this topic until the work is "done". I asked for consensus and I got it--thank you all! At 2026-05-11T10:46:39-0400, Chet Ramey wrote: > On 5/9/26 12:15 AM, G. Branden Robinson wrote: > > That is, of course, false. Terminal devices _can't change the font > > family_ and every terminal emulator that even weakly implements > > ECMA-48 lays out the screen as a uniform grid of character cells. > > That means that the font in use is _already monospaced_. > > > > Further, nothing about the rendering has changed on these devices. > > `\fC` was _always_ doing nothing in nroff mode.[3] It's just that > > now, GNU troff is _telling_ you that your command to it is, and > > always has been, futile (in nroff mode). Evidently that is > > unwelcome information. > > If it's a no-op in nroff, and does something reasonable in troff, man > page authors don't have to write .if t and .if n conditionals. > (Speaking as someone who used to use \f(CW to force a constant-width > font in troff.) I'm going to branch this topic off into a new thread to the groff list and CC Colin Watson (and you), because something I don't understand is going on with man-db man(1) that makes me wonder when people are even seeing these warnings. > > I think trying to get at inline Courier in man pages is a > > fool's errand. I'm not 100% opposed to introducing yet another > > new macro (pair--see below) to support it, because at least > > with a macro the package can evaluate the font-change > > instruction and try to do something sensible, and perhaps even > > string-configurable--but this solution faces multiple strong > > headwinds. > > > > First, many man(7) authors are besotted with `\f` escape > > sequences. > > I'd say that those were the prevailing style when I began to learn to > write man pages in the late 80s. (And what's worse is that the > existing man pages I used as guides used \f3 and \f2, for an example > of how we've evolved.) Yup. I've never seen it written down, but when I learned about the Old Days, I realized that "RIBS" was a good mnemonic for recalling the font mounting position assignments of Ossanna troff. Always makes me think of the M*A*S*H episode about "Adam's Ribs"... <eyes mailbox warily for inbound mail from the AARP> > For today? I don't know how common this is, but those inline font > changes are easier for me to use to emulate something like > > @code{( @var{command} )} > > and it helps me keep the text structure of the man page and info > document similar enough to spot typos and minor differences. Yeah, it's an advantage in that respect. I know I'll never get man page authors as a whole to give up their font escape sequences; the best I can do is try to convince people that using them has drawbacks, by spelling out what those drawbacks are. * The formatter can't distinguish typos from intentional but impossible * demands; * the macro package can't help you by checking font availability for itself and then falling back to something "reasonable" in context (and taking output device capabilities into account); * the identity of the "previous font", as selected by `\fP`, is inconsistent among implementations if an un-fulfillable selection is made;[1] * input like `\fIthis\fP` frustrates many spell checkers; and * groff man(7), at least, knows to apply italic corrections when the document sets upright and slanted glyphs adjacently. Maybe I should stick the foregoing into the "Notes" section, a kind of FAQ--except people mostly don't ask questions, but instead proclaim groff and its maintainers as stupid--of the groff_man_style(7) document. Such clarification won't reach the proclaimers, but it might reach other people. (And they won't have to walk five hundred miles to reach it...) > Since I maintain the bash documentation for two completely separate > and wildly different document formatters, sometimes it ends up with > the style of whichever one I used first when I write a particular > section of text. I understand. When deciding some years ago to take the least disruptive path and serve multiple masters (audiences) by maintaining groff's Texinfo manual in parallel with its man pages, despite some feeling on the part of one or two vocal *roff advocates that keeping Texinfo was some sort of tacit confession that groff wasn't up to the job of typesetting its own manual,[2]--which is nonsense--that I'd face challenges in maintaining synchrony and developing conventions to overcome issues where the two systems frustrated parallel syntax. And sure enough I regularly find places where the hyperactive content kitts have wriggled free of their enclosure. Doing this job perfectly demands, it seems, more discipline than I have. So I settle for doing it imperfectly, and trying to clearly define the objectives of groff's Texinfo manual.[3] Regards, Branden [1] https://lists.gnu.org/archive/html/groff-commit/2026-04/msg00342.html [2] https://lists.gnu.org/archive/html/groff/2020-02/msg00033.html https://lists.gnu.org/archive/html/groff/2022-07/msg00182.html [3] https://savannah.gnu.org/bugs/?60061
signature.asc
Description: PGP signature
