Linux Manual Pages development
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: Alejandro Colomar <alx@kernel.org>
Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>,
	kernel@collabora.com, linux-man@vger.kernel.org
Subject: managing tagged paragraphs (was: [PATCH 2/2] ioctl_pagemap_scan: add page for pagemap_scan IOCTL)
Date: Sat, 28 Oct 2023 08:07:14 -0500	[thread overview]
Message-ID: <20231028130714.inrfj5nzbqt25ms3@illithid> (raw)
In-Reply-To: <ZTefONm-aap2x1nF@debian>

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

Hi Alex,

At 2023-10-24T12:40:55+0200, Alejandro Colomar wrote:
> On Mon, Oct 23, 2023 at 09:48:02PM -0500, G. Branden Robinson wrote:
> > If one has learned device-independent troff's output language (see
> > groff_out(5)), one can see that the space after the comma is simply
> > discarded.
> 
> Hmm, I might use .grout for the similarity with that manual page name.
> ;)

Yes, I like the terms "trout" and "grout" for the original Kernighan
device-independent troff format and GNU's extended version of it,
respectively.  But I have met few other people who do.  :)

> > Good, yes.  I see what you're talking about.  We can now use
> > ioctl_pagemap_scan(2) as a site for our horrific medical experiments.
> > 3:-)
> > 
> > I think this is an instance of the tricky little constraint problem
> > Michael Kerrisk and I discussed almost 3 years ago.
> > 
> > https://lore.kernel.org/linux-man/a79fc055-c7ab-1793-04eb-eb4f678e5035@gmail.com/
> 
> Yep, and like Michael, I also dislike the line break.  Is there any
> chance that we could make it not break after TP so that it (RS) would
> be usable there?

The exhibit was roughly this (based on ioctl_pageman_scan(2)):

.TH foo 2 2023-10-28 "groff test suite"
.TP
.B vec
The address of
.I page_region
array for output.
.IP
.in +4n
.EX
struct page_region {
    __u64  start;
    __u64  end;
    __u64  categories;
};
.EE
.in
Other text.

This already formats without a line break after `TP`.

$ nroff -man -Tascii ATTIC/vec.man
foo(2)                        System Calls Manual                       foo(2)

       vec    The address of page_region array for output.

                  struct page_region {
                      __u64  start;
                      __u64  end;
                      __u64  categories;
                  };
              Other text.

groff test suite                  2023-10-28                            foo(2)

If the paragraph tag is long, man(7) will break the line after it.

$ nroff -man -Tascii ATTIC/vec.man
foo(2)                        System Calls Manual                       foo(2)

       vecvecvec
              The address of page_region array for output.

                  struct page_region {
                      __u64  start;
                      __u64  end;
                      __u64  categories;
                  };
              Other text.

groff test suite                  2023-10-28                            foo(2)

If you want to set the tag on the same line as the tag, you need to give
`TP` an argument indicating the desired width of the tag.  E.g.,
".TP 11n".

$ nroff -man -Tascii ATTIC/vec.man
foo(2)                        System Calls Manual                       foo(2)

       vecvecvec  The address of page_region array for output.

                      struct page_region {
                          __u64  start;
                          __u64  end;
                          __u64  categories;
                      };
                  Other text.

groff test suite                  2023-10-28                            foo(2)

If you want to _force_ a break after tag no matter its width, there are
a few ways, but for practical purposes, an inset region is useful.

I'm considerably elaborating the example here to illustrate the
adaptability of the "nest-RS-and-RE-within-TP" approach.

$ cat ATTIC/vec.man
.TH foo 2 2023-10-28 "groff test suite"
.TP
.B vec
.RS
The address of
.I page_region
array for output.
.P
Further details about page regions.
.RS
.P
.EX
struct page_region {
    __u64  start;
    __u64  end;
    __u64  categories;
};
.EE
.RE
.P
Further discussion of
.BR vec .
.RE
.P
We will talk about something else now.

$ nroff -man -Tascii ATTIC/vec.man
foo(2)                        System Calls Manual                       foo(2)

       vec
              The address of page_region array for output.

              Further details about page regions.

                     struct page_region {
                         __u64  start;
                         __u64  end;
                         __u64  categories;
                     };

              Further discussion of vec.

       We will talk about something else now.

groff test suite                  2023-10-28                            foo(2)

Notice how I needed neither `in` requests nor the `IP` macro for that.

This approach is fairly flexible, and still works for simple cases (but
does _force_ a break after the tag).

$ cat ATTIC/vec.man
.TH foo 2 2023-10-28 "groff test suite"
.TP
.B vec
.RS
The address of
.I page_region
array for output.
.RE
.TP
.B vec_len
The length of the
.I page_region
struct array.

$ nroff -man -Tascii ATTIC/vec.man
foo(2)                        System Calls Manual                       foo(2)

       vec
              The address of page_region array for output.

       vec_len
              The length of the page_region struct array.

groff test suite                  2023-10-28                            foo(2)

> Yup, but anyone new to man(7) will likely be put off by that page.
> 
> $ man groff_man_style | wc -l
> 1439

Because we don't know your terminal width, that number doesn't
communicate a lot.  But it is just shy of 20k words in groff 1.23.0.
The "reference" version, groff_man(7), is half as long.

> If you're just contributing a few paragraphs, you may prefer to learn
> by trial and error (which is a perfectly valid approach, and one that
> I prefer).

Experimentation is certainly superior to guessing (or assuming).

> Only when I wanted to learn the more obscure details, or quote
> to someone else, I've read that page (and I haven't read it entirely
> yet!).

I look forward to your critique from a position of practical experience.

Regards,
Branden

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

  reply	other threads:[~2023-10-28 13:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-19 13:12 [PATCH 1/2] ioctl_userfaultfd.2: add UFFD_FEATURE_WP_ASYNC Muhammad Usama Anjum
2023-10-19 13:12 ` [PATCH 2/2] ioctl_pagemap_scan: add page for pagemap_scan IOCTL Muhammad Usama Anjum
2023-10-23 21:52   ` Alejandro Colomar
2023-10-24  2:48     ` G. Branden Robinson
2023-10-24 10:40       ` Alejandro Colomar
2023-10-28 13:07         ` G. Branden Robinson [this message]
2023-10-28 16:22           ` managing tagged paragraphs (was: [PATCH 2/2] ioctl_pagemap_scan: add page for pagemap_scan IOCTL) Alejandro Colomar
2023-10-28 18:07             ` G. Branden Robinson
2023-10-29  0:42               ` Alejandro Colomar
2023-10-24 15:51     ` [PATCH 2/2] ioctl_pagemap_scan: add page for pagemap_scan IOCTL Muhammad Usama Anjum
2023-10-19 13:27 ` [PATCH 1/2] ioctl_userfaultfd.2: add UFFD_FEATURE_WP_ASYNC Alejandro Colomar
2023-10-19 13:29 ` Alejandro Colomar
2023-10-19 13:34   ` Muhammad Usama Anjum
2023-10-19 13:42     ` Alejandro Colomar

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=20231028130714.inrfj5nzbqt25ms3@illithid \
    --to=g.branden.robinson@gmail.com \
    --cc=alx@kernel.org \
    --cc=kernel@collabora.com \
    --cc=linux-man@vger.kernel.org \
    --cc=usama.anjum@collabora.com \
    /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