From: Alejandro Colomar <alx.manpages@gmail.com>
To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
Cc: linux-man <linux-man@vger.kernel.org>, enh <enh@google.com>
Subject: Re: italicizing pointer stars (was: [PATCH] getline.3: wfix.)
Date: Fri, 5 Aug 2022 21:40:06 +0200 [thread overview]
Message-ID: <d53c704c-c02a-7361-2cef-5cd97c5aa282@gmail.com> (raw)
In-Reply-To: <20220805192007.iwwu4e2n45hqw4cn@illithid>
[-- Attachment #1.1: Type: text/plain, Size: 1929 bytes --]
Hi Branden,
On 8/5/22 21:20, G. Branden Robinson wrote:
> At the risk of opening another typographical can of worms...
>
> At 2022-08-02T14:17:24-0700, enh wrote:
>> diff --git a/man3/getline.3 b/man3/getline.3
>> index 8b7357825..cb9e5b049 100644
>> --- a/man3/getline.3
>> +++ b/man3/getline.3
>> @@ -36,12 +36,12 @@ Feature Test Macro Requirements for glibc (see
>> .BR getline ()
>> reads an entire line from \fIstream\fP,
>> storing the address of the buffer containing the text into
>> -.IR "*lineptr" .
>> +.IR *lineptr .
> [several other instances in same page snipped]
>
> I'm wondering if we should really be setting the dereferencing operator
> in italics here.
>
> In declarations, the star is part of the _type_, not the identifier.
> Similarly, in expressions, the star is an operator, like "+", not part
> of the identifier.
Let me escape out of this a bit sideways :P
*foo, as a whole, is an expression, consisting of an operator and an
identifier. So I won't apply identifier rules for highlighting, but
expression rules. The rules for marking expressions up are:
man-pages(7):
Formatting conventions (general)
[...]
Expressions, if not written on a separate indented line,
should be specified in italics. Again, the use of non‐
breaking spaces may be appropriate if the expression is
inlined with normal text.
And the deep rationale why I would like to avoid having the star in a
different font is that it could be confused with the glob-like
expressions that we use for example to refer to SYS_* macros. (And,
BTW, I should apply some consistency fixes to those too, since they are
in many cases highlighted in bold, as the rest of the identifier --and
that is plain wrong--.)
Did I dodge the bullet?
Cheers,
Alex
--
Alejandro Colomar
<http://www.alejandro-colomar.es/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-08-05 19:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-29 20:22 [PATCH] getline.3: wfix enh
2022-07-29 20:52 ` G. Branden Robinson
2022-07-29 20:55 ` enh
2022-08-01 12:53 ` Alejandro Colomar
2022-08-02 21:17 ` enh
2022-08-05 19:20 ` italicizing pointer stars (was: [PATCH] getline.3: wfix.) G. Branden Robinson
2022-08-05 19:40 ` Alejandro Colomar [this message]
2022-08-05 21:49 ` G. Branden Robinson
2022-08-05 21:56 ` Alejandro Colomar
2022-08-15 21:16 ` [PATCH] getline.3: wfix 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=d53c704c-c02a-7361-2cef-5cd97c5aa282@gmail.com \
--to=alx.manpages@gmail.com \
--cc=enh@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox