From: Alejandro Colomar <alx@kernel.org>
To: astian <astian@memeware.net>
Cc: "G. Branden Robinson" <g.branden.robinson@gmail.com>,
linux-man <linux-man@vger.kernel.org>
Subject: Re: ioperm(2): confusing terminology
Date: Thu, 17 Sep 2026 21:34:44 +0200 [thread overview]
Message-ID: <aqw_5T8A06FPdRJ6@devuan> (raw)
In-Reply-To: <DLHTUAUL26OP.JKIAQT055DTD@memeware.net>
[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]
Hi astian,
> Date: 2026-09-17 19:09:41+0000
> From: astian <astian@memeware.net>
>
[...]
> > I don't know how you read .md or .rst, but I read them in the terminal,
> > usually with less(1), which doesn't reflow them.
>
> But you read the rendered manpage, the output of running groff (and co.)
> on the manpage source, right? If you were to read manpage sources with
> less in the terminal there wouldn't be reflowing either, naturally.
>
> The point I was making is that newlines in groff_man pages did not seem
> to be more semantic than those in adoc/md/rst/whatever. Upon rendering,
> paragraph lines are reflowed. After Robinson's explanation I can see 1
> bit of meaning to them (sentence delimiters).
Yeah, if we used it exclusively as source for formatted manual pages
--just like man(7) is used now--, then I'd be fine reading the formatted
pages.
However, as you said in another email, that would delete the unique
advantage of .md/.rst, and the source would read as bad as man(7) source
(IMO, worse, because the formatting macros would be replaced by weird
pubctuation, which is more difficult to control --as we've seen in a
recent mail too--).
I believe kernel maintainers would run away fro .rst if they used
semantic newlines and thus had to format them to read them nicely.
> > Is there any program for reading these in the terminal reflowed?
>
> I guess there are although I don't personally use one (of course, that's
> the point of these "light markup" formats: they mostly look like plain
> text so you don't much need a renderer). For example, there are plenty
> of tools to convert these formats to HTML which can then be viewed in a
> terminal browser. Or one could use pandoc to convert them to *roff
> and... haha ;).
Yeah, it ain't going to work. Luckily, we've got man(7). :-)
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-09-17 19:34 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 [this message]
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 ` ioperm(2): confusing terminology G. Branden Robinson
2026-09-17 13:18 ` 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=aqw_5T8A06FPdRJ6@devuan \
--to=alx@kernel.org \
--cc=astian@memeware.net \
--cc=g.branden.robinson@gmail.com \
--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