public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: "Jakub Wilk" <jwilk@jwilk.net>,
	наб <nabijaczleweli@nabijaczleweli.xyz>,
	linux-man@vger.kernel.org
Subject: Re: [PATCH 1/3] timespec.3type: tv_nsec is impl-def-type, glibc llong not a bug
Date: Mon, 30 Jan 2023 07:50:30 -0600	[thread overview]
Message-ID: <20230130135030.yj7dcbcdj35xwap2@illithid> (raw)
In-Reply-To: <34f497d7-7aba-84b6-c9b8-1d8bbcf183e5@gmail.com>

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

Hi Alex,

At 2023-01-30T14:15:50+0100, Alejandro Colomar wrote:
> On 1/30/23 08:08, Jakub Wilk wrote:
> > * Alejandro Colomar <alx.manpages@gmail.com>, 2023-01-29 16:48:
> > > > +.BR "    /*\(da*/   tv_nsec;" "  /* Nanoseconds [" 0 ", " 999999999 "] */"
> > > 
> > > I'm tempted to merge this patch.  It's sooo qute /*↓*/
> > 
> > I want man pages legible, not cute.
> 
> I know, I know.
> 
> > Please make it
> > 
> >    /* see below */ tv_nsec
> > 
> > or maybe
> > 
> >    long /* but see below */ tv_nsec
> > 
> > (given that C23 is not a thing yet).
> 
> The reason why I seriously considered /*↓*/ is that it is a bit
> shocking to the reader, which will prompt it to read the rest of the
> page to see what the hell that is.

Even more shocking will be 'v', which is what it will degrade to on
ASCII, ISO 8859, and code page 1047 terminals.  On top of being
startling, it will look simply like an error.

> I'm worried that if we make it `long` plus a comment to see below,
> many will ignore it.

That's on them.  "/* see below */" means what it says.  A person cannot
reasonably claim they weren't warned.

> /* see below */ with no mentions to `long` might be a reasonable
> alternative. Maybe I'd use /* ... */
> 
> What do y'all think about it?

I think

long /* see below */ tv_nsec;

meets the requirements at issue.

Regards,
Branden

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

  reply	other threads:[~2023-01-30 13:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-28 14:17 [PATCH 1/3] timespec.3type: tv_nsec is impl-def-type, glibc llong not a bug наб
2023-01-28 14:17 ` [PATCH 2/3] clock_getres.2, clock_getcpuclockid.3, pthread_getcpuclockid.3: fix tv_nsec formatting наб
2023-01-28 14:17 ` [PATCH 3/3] man2/clock_getres.2, man2/clock_nanosleep.2, man2/nanosleep.2, man2/timer_settime.2, man2/timerfd_create.2, man2/utimensat.2, man3/mq_send.3, man3/pthread_tryjoin_np.3, man3/sem_wait.3: standardise on "range [0, 999999999]" for tv_nsec наб
2023-01-29 15:48 ` [PATCH 1/3] timespec.3type: tv_nsec is impl-def-type, glibc llong not a bug Alejandro Colomar
2023-01-29 16:29   ` наб
2023-01-29 16:31     ` [PATCH v2 " наб
2023-01-29 16:41       ` Alejandro Colomar
2023-01-30  2:05         ` наб
2023-01-30 12:56           ` Alejandro Colomar
2023-01-29 16:31     ` [PATCH v2 2/3] clock_getres.2, clock_getcpuclockid.3, pthread_getcpuclockid.3: fix tv_nsec formatting наб
2023-01-29 16:31     ` [PATCH v2 3/3] man2/clock_getres.2, man2/clock_nanosleep.2, man2/nanosleep.2, man2/timer_settime.2, man2/timerfd_create.2, man2/utimensat.2, man3/mq_send.3, man3/pthread_tryjoin_np.3, man3/sem_wait.3: standardise on "range [0, 999\(aq999\(aq999]" for tv_nsec наб
2023-01-30  7:08   ` [PATCH 1/3] timespec.3type: tv_nsec is impl-def-type, glibc llong not a bug Jakub Wilk
2023-01-30 13:15     ` Alejandro Colomar
2023-01-30 13:50       ` G. Branden Robinson [this message]
2023-01-30 13:54         ` Alejandro Colomar
2023-01-30 19:47           ` Brian Inglis
2023-01-30 18:38       ` [PATCH v3 " наб
2023-02-05 15:39         ` Alejandro Colomar
2023-02-05 15:49           ` наб
2023-02-05 16:09             ` 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=20230130135030.yj7dcbcdj35xwap2@illithid \
    --to=g.branden.robinson@gmail.com \
    --cc=alx.manpages@gmail.com \
    --cc=jwilk@jwilk.net \
    --cc=linux-man@vger.kernel.org \
    --cc=nabijaczleweli@nabijaczleweli.xyz \
    /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