Re: [PATCH] recv.2: msg_iovec / MSG_ERRQUEUE / -v

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3398 bytes --]

Hi,

On 2023-07-16 04:34, G. Branden Robinson wrote:
[...]

> Because natural language demands a bit of Postel's Law, the foregoing
> are generally understood by English speakers despite their non-standard
> structure.
> 
[...]

>> BTW, that's the only case where it says to not use hyphens, and since
>> by being alone it's necessarily not following a noun, I'd say it
>> doesn't fall in this rule, and so a hyphen would be deserved.
> 
> I'd agree.  I cite authorities only because I cannot expect people to
> take only my word at such things.  My authority as a grammarian is
> limited.  Unlike some, I don't have God and Ayn Rand for parents.

And yet your words make more sense than those of the "authorities".  ;)

> 
>> I don't see reasons to avoid it in the links above.
>>
>> So, I'm tending to conclude that it's necessary, or at least useful or
>> tasteful.  Please quote the relevant parts if you disagree.

I should have said, or decree their authority rescinded in our territories.
They no authority here no mo.  :D

> 
> Recalling the case at issue:
> 
> .BR MSG_ERRQUEUE " (" recvmsg "() only; since Linux 2.2)"
> 
> I would find the addition of a hyphen before "only" to be superfluous.
> As I said before, it disambiguates nothing.  Further, if any of these
> annotations ever has to be compounded, as in a man page that documents
> several functions but requires annotation only for a subset of them, the
> use of hyphens as you intend is liable to add clutter.
> 
> .BR MSG_BAZQUEUE " (" foomsg "()-, " barmsg "()-only; since Linux 7.99)"
> 
> Consider also the possibility that you may want to invert set
> membership; perhaps 6 out of 7 functions in a page accept a certain
> parameter.
> 
> .BR MSG_BAZQUEUE " (not " quxmsg "(); since Linux 7.99)"
> 
> There is no correct place for a hyphen here.

Yeah, a hyphen is better omitted for your reasons.

---  Mr. Sed project:

> 
> Will do.  I've gotten sidetracked by the great automated "Mr. Sed"[1]
> project, which turns out to have some prerequisites if I am to
> demonstrate no changes in formatted text as I intend.
> 
> Early findings:
> 
> 1.  I think I have raised warnings to this list before about
>     manipulating adjustment and hyphenation outside of table regions
>     with `ad` and `hy` requests; the Linux man-pages do so
>     systematically around hundreds of tables, attempting (but failing)
>     to (reliably) "reset" them after tables, often with miserable
>     results.  Fixing this is a separate, prior sed(1) project.

Great.

> 
> 2.  An ".sp 1" hack, also after tables, to work around a groff
>     pre-1.23.0 bug is also not necessary and the time to sweep it away
>     is near.

While it may not be necessary, I'm all-in for killing such a workaround
ASAP, to avoid contributors from imitating it.

Cheers,
Alex

>  I may not _have_ to do this one to satisfy "Mr. Sed",
>     though.  I will keep you advised.
> 
> Regards,
> Branden
> 
> [1] the rewrite of man page cross references to use the new groff 1.23.0
>     `MR` macro, a feature I have written about on this list before and
>     which is covered in the release announcement sent here earlier this
>     month by Bertrand Garrigues

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


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