At the risk of opening another typographical can of worms... At 2022-08-02T14:17:24-0700, enh wrote: > diff --git a/man3/getline.3 b/man3/getline.3 > index 8b7357825..cb9e5b049 100644 > --- a/man3/getline.3 > +++ b/man3/getline.3 > @@ -36,12 +36,12 @@ Feature Test Macro Requirements for glibc (see > .BR getline () > reads an entire line from \fIstream\fP, > storing the address of the buffer containing the text into > -.IR "*lineptr" . > +.IR *lineptr . [several other instances in same page snipped] I'm wondering if we should really be setting the dereferencing operator in italics here. In declarations, the star is part of the _type_, not the identifier. Similarly, in expressions, the star is an operator, like "+", not part of the identifier. Before answering, consider also the common practice of "setting all literals in bold". I think this habit is over-applied, and thus I do not articulate it in groff_man_style(7)[1]. Here, an insistence upon it in the above-quoted case leads us straight into the three-font problem, and an especially devilish case of it to boot. We would need... .BI * lineptr\c \&. ...where our man page contributors find not only that they need to apply the historically nigh-incomprehensible `\c` escape sequence,[2] but also have to remember to put the ineffable `\&` escape sequence[3] at the start of the line so that the period will be formatted (rather than interpreted as the *roff control character). If the consensus is that applying the "literals in bold" convention would indeed be too painful, then I suggest adding a style note regarding this point to man-pages(7), and explaining why it was adopted. I can propose some language for that. There _is_ another way to skin this cat.[4] .B *\c .IR lineptr . Maybe that would be preferable. Regards, Branden [1] https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/groff_man.7.man.in [2] I believe it is explained clearly here. https://git.savannah.gnu.org/cgit/groff.git/tree/doc/groff.texi#n9509 [3] An argument has been raging on the groff mailing list over the best nomenclature for `\&` for some time. https://savannah.gnu.org/bugs/index.php?62816 [4] I reject the use font selection escape sequences out of hand.
Attachment:
signature.asc
Description: PGP signature
