From: qwx@sciops.net
To: 9front@9front.org
Subject: Re: [9front] 9front man pages
Date: Fri, 08 Mar 2024 10:01:04 +0100 [thread overview]
Message-ID: <EA8E7DD33E1DC38BE5AB791865BDA5F1@wopr.sciops.net> (raw)
In-Reply-To: <ZeqiEWu01G2SoTkT@simple-cc.openbsd.amsterdam>
On Fri Mar 8 06:28:55 +0100 2024, k0ga@shike2.com wrote:
> Hi,
>
> On Thu, Mar 07, 2024 at 11:07:14PM -0600, Jacob Moody wrote:
> > I am also not sure what you mean by "Runtime options are listed for
> > readability", do you mean to have a table layout for all command line
> > options consistently? If so I also would not personally be a fan of that.
>
> I agree with Moody here. The 9front man pages are written from the point
> of view of a full lecture of the page, giving a good organization of the
> text and relating options between them. Moving to have a table of options
> will enforce a bad documentation culture where the full overall reason of
> the options is lost because they are dealt individually. I think the
> SYNOPSIS section is already providing a good summary.
This has been argued over before and I personally disagree with the
notion of having to read the entire manpage just to find the one flag
I'm interested in. I would much prefer (with much bias) the
style/format in ipconfig(8) or wadfs(4), combining both. Then again
that's simply not practical in some cases, so as Ori said it should be
dealt on a case by case basis.
On Fri Mar 8 05:47:24 +0100 2024, eso@self.rodeo wrote:
> I'd like to hear what others think. Also I was thinking this would just
> cover system usage sections like userland, system administration, file
> servers, etc. But if it goes well, maybe we can go beyond that. The last
> patch I submitted, for acmed(8), Ori had some objections about my
> phrasing. So it seems I could use some advisement. But for the record, I
> have experience with technical writing.
I think there's no point in trying to come up with a general directive
which everyone agrees on; just between us with Ori, moody and k0ga, we
agree on most points, but not all. I suggest that you just pick
manpages you would like to improve, and write a patch, so something
more specific could be discussed.
Cheers,
qwx
next prev parent reply other threads:[~2024-03-08 9:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-08 4:47 eso
2024-03-08 5:07 ` Jacob Moody
2024-03-08 5:28 ` Roberto E. Vargas Caballero
2024-03-08 9:01 ` qwx [this message]
2024-03-08 11:30 ` hiro
2024-03-08 11:34 ` hiro
2024-03-08 11:35 ` hiro
2024-03-08 16:01 ` eso
2024-03-08 16:24 ` qwx
2024-03-08 5:23 ` ori
2024-03-08 17:40 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2024-03-08 18:30 ` hiro
2024-03-08 23:20 ` umbraticus
2024-03-08 23:50 ` ori
2024-03-09 0:40 ` sl
2024-03-09 1:08 ` hiro
2024-03-09 1:36 ` Stanley Lieber
2024-03-09 11:01 ` sirjofri
2024-03-10 19:16 ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2024-03-10 21:05 ` sirjofri
2024-03-10 21:11 ` hiro
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=EA8E7DD33E1DC38BE5AB791865BDA5F1@wopr.sciops.net \
--to=qwx@sciops.net \
--cc=9front@9front.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).