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: astian <astian@memeware.net>, linux-man <linux-man@vger.kernel.org>
Subject: Re: ioperm(2): confusing terminology
Date: Thu, 17 Sep 2026 07:38:45 -0500	[thread overview]
Message-ID: <20260917123845.valu5ro5zur23o56@illithid> (raw)
In-Reply-To: <aqvHRZ7DfbdG5XBt@devuan> <aqvVeSW_dHnYbwca@devuan>

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

Hi Alex,

At 2026-09-17T13:00:30+0200, Alejandro Colomar wrote:
> > Date: 2026-09-17 07:04:37+0000
> > From: astian <astian@memeware.net>
> > On 14 Sep 2026 14:56 +0200, Alejandro Colomar wrote:
> > [...]
> > > One thing that is very important is that we use semantic newlines.
> > > That discards .md and .rst, since they are meant to be written
> > > with paragraphs as they'd be read by humans.
> > 
> > Sorry, I didn't read groff_man fully, but I'm curious: what is the
> > meaning of newlines in man that gets lost in those other formats?
> 
> They have no meaning.

I wouldn't go that far.

Like TeX, *roff uses newlines, _in context_, to help it automatically
decide where sentence boundaries are.

Because the formatter, not the macro package, makes that decision, the
rules are documented not in groff_man_(7), but roff(7) and groff's
Texinfo manual.  If a person follows the "semantic newline" guidance
from man-pages(7), they can worry less often about what the rules for
automatic sentence boundary detection are.

roff(7):

Input conventions
     Since a roff formatter fills text automatically, its experienced
     users tend to avoid visual composition of text in input files: the
     esthetic appeal of the formatted output is what matters.
     Therefore, roff input should be arranged such that it is easy for
     authors and maintainers to compose and develop the document,
     understand the syntax of roff requests, macro calls, and
     preprocessor languages used, and predict the behavior of the
     formatter.  Several traditions have accrued in service of these
     goals.

     •  Follow sentence endings in the input with newlines to ease their
        recognition.  It is frequently convenient to end text lines
        after colons and semicolons as well, as these typically precede
        independent clauses.  Consider doing so after commas; they often
        occur in lists that become easy to scan when itemized by line,
        or constitute supplements to the sentence that are added,
        deleted, or updated to clarify it.  Parenthetical and quoted
        phrases are also good candidates for placement on text lines by
        themselves.

Following this practice also helps keep document revisions from
"bleeding" into unaltered adjacent sentences in a diff.  (I think it's
worth studying why the Markdown/AsciiDoc/"plain text markup" communities
have not independently re-created this practice.)

> > diff --git a/man/man2/ioperm.2 b/man/man2/ioperm.2
> > index e4a058164f6f..9b9aaf3840e2 100644
> > --- a/man/man2/ioperm.2
> > +++ b/man/man2/ioperm.2
> > @@ -4,7 +4,7 @@
> >  .\"
> >  .TH ioperm 2 (date) "Linux man-pages (unreleased)"
> >  .SH NAME
> > -ioperm \- set port input/output permissions
> > +ioperm \- set input/output port permissions
> 
> If I'm understanding this proposal correctly, the fix is because I/O
> is an adjective of port, not of permissions.  And then 'I/O port'
> would be modifying permissions.

The parse is not quite that rigid, but the proposed change helps steer
the reader to the correct one.

> If my interpretation is correct, then I believe I/O would be separated
> from 'port' by a hyphen, not a space.

Not the case!

One does not say:

  *I am a Linux-kernel programmer.

but rather this.

   I am a Linux kernel programmer.

Generally, in English, you can chain nouns that function as adjectives
to an almost silly degree.  I recall a favorite example from
alt.usage.english on Usenet many years ago.  Here is a noun phrase.

  sump pump backup alarm silencer switch

What kind of switch is it?  A silencer.

A silencer for what?  The alarm.

An alarm for what condition?  Backup.

Backup of what?  A pump.

What sort of pump?  A sump pump.[1]

> Is this the correct interpretation of the proposed fix?
> 
> BTW, should we contract to I/O?
> 
> 	ioperm \- set I/O-port permissions

I have no strong opinion on the ordering, but a hyphen does not belong
there.

Regards,
Branden

[1]  The word "sump" is almost never seen in isolation in general usage.
     One doesn't typically say the following.

       My basement flooded in the storm.  I'm standing in the sump and
       water is up to my ankles.

    It parses, and is grammatical and meaningful, but it would sound
    odd.  Maybe not to a plumber, though.

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

  reply	other threads:[~2026-09-17 12:38 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-12 22:00 ioperm(2): confusing terminology astian
2026-09-12 22:24 ` Alejandro Colomar
2026-09-12 22:48   ` Alejandro Colomar
2026-09-13  6:29   ` astian
2026-09-14 12:56     ` Alejandro Colomar
2026-09-15 15:39       ` Markdown as a "less hairy" source format for man pages (was: ioperm(2): confusing terminology) G. Branden Robinson
2026-09-17  7:05         ` Markdown as a "less hairy" source format for man pages astian
2026-09-17  7:04       ` ioperm(2): confusing terminology astian
2026-09-17 11:00         ` Alejandro Colomar
2026-09-17 19:09           ` astian
2026-09-17 19:34             ` Alejandro Colomar
2026-09-17  6:16   ` [PATCH 1/2] man/man2/ioperm.2: Reword slightly for clarity astian
2026-09-17 11:59     ` Alejandro Colomar
2026-09-17  6:16   ` [PATCH 2/2] man/man2/ioperm.2: wfix astian
2026-09-17 11:59     ` Alejandro Colomar
2026-09-17 12:38       ` G. Branden Robinson [this message]
2026-09-17 13:18         ` ioperm(2): confusing terminology Alejandro Colomar
2026-09-17 19:08         ` astian
2026-09-17 23:02           ` G. Branden Robinson
2026-09-17 19:11       ` [PATCH 2/2] man/man2/ioperm.2: wfix astian
2026-09-17 19:58       ` [PATCH] man/man5/proc_ioports.5: wfix astian
2026-09-17 23:09         ` G. Branden Robinson
2026-09-17 23:16           ` Alejandro Colomar
2026-09-18  7:03         ` [PATCH v2] " astian
2026-10-11 17:11           ` Alejandro Colomar
2026-09-17 19:57     ` [PATCH v2] man/man2/ioperm.2: wfix astian
2026-10-11 17:12       ` Alejandro Colomar
2026-10-11 17:13         ` Alejandro Colomar
2026-10-11 20:25           ` astian

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=20260917123845.valu5ro5zur23o56@illithid \
    --to=g.branden.robinson@gmail.com \
    --cc=alx@kernel.org \
    --cc=astian@memeware.net \
    --cc=linux-man@vger.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