linux-man.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: "Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
Cc: "Pali Rohár" <pali@kernel.org>,
	linux-man@vger.kernel.org,
	"Michael Kerrisk" <mtk.manpages@gmail.com>
Subject: Re: [PATCH] termios.3: SPARC architecture has 4 different Bnnn constants
Date: Wed, 4 Aug 2021 16:14:27 +1000	[thread overview]
Message-ID: <20210804061425.yde647cvq3wy4stw@localhost.localdomain> (raw)
In-Reply-To: <31c0e6d7-0b5c-19dd-bfcb-01e703ed2008@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3757 bytes --]

Hi, Alex!

At 2021-08-01T14:13:39+0200, Alejandro Colomar (man-pages) wrote:
> On 8/1/21 1:22 PM, G. Branden Robinson wrote:
> When I saw the patch, I had no idea what those .ft/.fi things do, and
> guessed that they're correct based on existing context.  I think your
> replacement suggestion below is better.

The 'ft' request changes the font (or style), and accepts exactly the
same parameter as the \f font (style) escape.

The 'fi' request enables filling; 'nf' disables it.

> > Here's how I'd do that:
> > 
> > .P
> > On the SPARC architecture,
> > the following additional constants are supported.
> > .RS
> > .TP
> > .B B76800
> > .TQ
> > .B B153600
> > .TQ
> > .B B307200
> > .TQ
> > .B  B614400
> > .RE
> > 
> > Why would I do it this way?  I'm trying to keep the size of the
> > language we ask man page writers to learn as small as possible, and
> > I especially try to keep the number of *roff requests they have to
> > know as close to zero as possible.  There are already two ways to
> > change fonts: through macros and escape sequences.  Personally, I'd
> > like to protect casual man page writers from having to learn the
> > third.  (And, again, outside of tbl(1) tables, I'd prefer they not
> > have to know the second [escapes].)
> 
> Can you please send a more detailed email about what the current
> implementation does and how compatible is the solution and any
> differences there may be (if any)?

Sure, I'll mark 'em up like assembly.  I hope your mail reader uses a
monospaced/fixed-width font.

.fi			\" enable filling[1] of text
.PP			\" man(7) paragraphing macro; see groff_man(7)
On SPARC architecture	\" text line
.PP			\" man(7) paragraphing macro; see groff_man(7)
.nf			\" disable filling of text
.ft B			\" change font to style "B"
	B76800		\" text line using literal tab
	B153600		\" ditto
	B307200		\" ditto
	B614400		\" ditto
.ft P			\" change font to "previous" selection
.fi			\" enable filling[1] of text

Here's how I define filling in the groff Texinfo manual; many other
sources define it equivalently.

    GNU 'troff' reads its input character by character, collecting words
 as it goes, and fits as many words together on an output line as it
 can--this is known as "filling".  To GNU 'troff', a "word" is any
 sequence of one or more characters that aren't spaces, tabs, or
 newlines.  Words are separated by spaces, tabs, newlines, or file
 boundaries.(2)  (*note Filling-Footnote-2::) To disable filling, see
 *note Manipulating Filling and Adjustment::.

I try to avoid use of tab characters in man page sources, except to
separate columns in tbl(1) input.  I prefer to use the relative inset
feature (.RS/.RE) because the default size of a relative inset is a
configurable parameter.  (And if must be a certain value, it can be set
as the argument to the RS macro.)

.P			\" man(7) paragraphing macro; see groff_man(7)
On the SPARC[...]
the following[...]
.RS			\" begin relative inset
.TP			\" begin tagged paragraph
.B B76800		\" set argument in bold style
.TQ			\" declare additional paragraph tag
.B B153600		\" [repeat previous two lines]
.TQ			\"
.B B307200		\"
.TQ			\"
.B  B614400		\"
.RE			\" end relative inset.

.RS and .RE are used with timidity by man page authors; I think it is
because they are ill-understood.  It is certainly not because they are
new; like .B and .TP they date back to the original 1979 man(7)
implementation.  Even .P is "new", dating to Unix System III in 1980.
.TQ is the real newcomer, introduced to groff in January 2007.  Like
.TP, it's somewhat semantic.

> I'd like to be able to fix that.

Let me know if I can shed more light on things.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-08-04  6:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-31 14:55 [PATCH] termios.3: SPARC architecture has 4 different Bnnn constants Pali Rohár
2021-08-01 10:55 ` Alejandro Colomar (man-pages)
2021-08-01 11:22 ` G. Branden Robinson
2021-08-01 12:13   ` Alejandro Colomar (man-pages)
2021-08-04  6:14     ` G. Branden Robinson [this message]
2021-09-10 22:17       ` Alejandro Colomar (man-pages)
2021-08-01 11:35 ` [PATCH v2] " Pali Rohár
2021-08-01 12:16   ` Alejandro Colomar (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210804061425.yde647cvq3wy4stw@localhost.localdomain \
    --to=g.branden.robinson@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=pali@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).