From: Alejandro Colomar <alx@kernel.org>
To: DJ Delorie <dj@redhat.com>
Cc: g.branden.robinson@gmail.com, linux-man@vger.kernel.org
Subject: Re: man/man8/ldconfig.8: document system-wide tunables
Date: Thu, 16 Jul 2026 02:07:59 +0200 [thread overview]
Message-ID: <algfTMXXsxKV9xGT@devuan> (raw)
In-Reply-To: <xnik6g6i48.fsf@greed.delorie.com>
[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]
Hi DJ,
On 2026-07-15T17:46:47-0400, DJ Delorie wrote:
> Alejandro Colomar <alx@kernel.org> writes:
> > I find it easier to write documentation in man(7) than in any other
> > languages. It's simple enough that I don't need to remember much.
>
> I can say the same for HTML, because I'm used to it and I stick to
> simple constructs. It's good that there are people who find man(7)
> easy, and it's good that those people have found a way to contribute
> using their expertese. I.e. Thank You :-)
Thanks! :-)
> >> I've always advocated for "whatever system means the docs are stored and
> >> edited with the code, that I can turn into whatever I need."
[...]
> I mean "anything that means one commit has code change and doc change".
> I don't care about the mechanism. Do it either way as long as you do
> something.
I see; that makes sense. In general, I agree; in this specific case,
I prefer it split, for other reasons, but yep.
> > You're welcome to send the patches well before they're merged in glibc.
>
> Er, I've been working on tunables for about 3-4 years now. I doubt
> you'd want to hold on to a patch set that long.
I would be happy to review a patch until it's fine, discard it locally,
and let you re-send it in 4 years (bonus points if it's In-Reply-To the
original one, so I can keep track of the history easily).
> In this case, the timing was poor - it finished up just before a release
> cycle, so whether the man pages needed to be done now or in six months
> was not known until the last minute. The time from glibc freeze to
> glibc release is plenty long enough for a man page review cycle, though.
Ok.
> > For the tests in the build system, I use MANWIDTH=80,
> > precisely to maintain a consistent width that is the most common one.
>
> I don't think I've had a default with of 80 for a couple decades now. I
> wish we'd standardized on the 132-column terminals instead.
I have a big screen, and when I switched to it, I thought I could use
more columns. What ended up happening is that I've increased the font
size to keep my eyes healthy. :D
If I split my screen in two (which I often do), the terminal has 88
columns. Considering that I enable column numbers in vim(1), I still
get to use around 80 columns for actual work.
> > So, it's at least as old as 1994. :)
>
> Um, my career predates that too. I don't think I was doing man pages
> back then, though.
Heh!
Cheers,
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-07-16 0:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 18:53 man/man8/ldconfig.8: document system-wide tunables DJ Delorie
2026-07-10 14:31 ` Alejandro Colomar
2026-07-10 18:12 ` DJ Delorie
2026-07-10 19:58 ` Why we're stuck with man(7) (was: man/man8/ldconfig.8: document system-wide tunables) G. Branden Robinson
2026-07-10 22:11 ` DJ Delorie
2026-07-10 22:28 ` Alejandro Colomar
2026-07-10 22:19 ` DJ Delorie
2026-07-10 20:06 ` man/man8/ldconfig.8: document system-wide tunables Alejandro Colomar
2026-07-10 20:33 ` Alejandro Colomar
2026-07-13 16:24 ` DJ Delorie
2026-07-13 20:16 ` Alejandro Colomar
2026-07-13 21:33 ` DJ Delorie
2026-07-13 22:22 ` G. Branden Robinson
2026-07-14 6:56 ` G. Branden Robinson
2026-07-15 2:34 ` DJ Delorie
2026-07-15 12:47 ` Alejandro Colomar
2026-07-15 14:33 ` DJ Delorie
2026-07-15 16:54 ` G. Branden Robinson
2026-07-15 18:19 ` DJ Delorie
2026-07-15 19:47 ` G. Branden Robinson
2026-07-15 20:46 ` DJ Delorie
2026-07-15 21:09 ` Alejandro Colomar
2026-07-15 21:46 ` DJ Delorie
2026-07-16 0:07 ` Alejandro Colomar [this message]
2026-07-15 17:09 ` Alejandro Colomar
2026-07-15 18:55 ` DJ Delorie
2026-07-15 23:37 ` Alejandro Colomar
2026-07-13 22:53 ` 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=algfTMXXsxKV9xGT@devuan \
--to=alx@kernel.org \
--cc=dj@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.