From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stepnem@smrk.net>
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS20473 45.76.80.0/20
X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,
	SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6
Received: from mail.smrk.net (mail.smrk.net [45.76.87.244])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512)
	(No client certificate requested)
	by dcvr.yhbt.net (Postfix) with ESMTPS id 3D60B1F55F
	for <meta@public-inbox.org>; Sat,  2 Sep 2023 19:08:28 +0000 (UTC)
Authentication-Results: dcvr.yhbt.net;
	dkim=pass (2048-bit key; unprotected) header.d=smrk.net header.i=@smrk.net header.a=rsa-sha256 header.s=20221002 header.b=eCl9tjRz;
	dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smrk.net; s=20221002;
	t=1693681706;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references;
	bh=S04Cfb8OF6bdMEvvY7goLmpG7sk3ntLiKza+Oa44FOE=;
	b=eCl9tjRzjbxBssh3gmcRALVgpv5F4rSx4zIlUlmftGA8ogt6cDmBCyi/zkK4si8lPQACfw
	Rk8GhDtsTRS08mY6f6Y7zCzAGWyaDY/5PfbL8HnYp4xqGmHxOqV7mzxXFhFjShsfr4PPkK
	T2rcyGE2MEOPcQzu5cxGMooOYdwBEaUj4yKvcVIZPrV78l2u+nR2RoVLk6i31sTpzU3WJJ
	1STNm/8Bxojy1rxaO2MN5LJ344hq2aCd76VbvfnxaSAktUgU8vAh5bOtk4amrEtHZX9rSY
	Y6ZqxNZpmGNibwZC7zByPIHTfhNbASsCIj55DQNiyRQTRjFO8cpEoozd3VdOng==
Received: from localhost (<unknown> [192.168.5.2])
	by smrk (OpenSMTPD) with ESMTPSA id c7586e39 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Sat, 2 Sep 2023 21:08:25 +0200 (CEST)
From: =?utf-8?B?xaB0xJtww6FuIE7Em21lYw==?= <stepnem@smrk.net>
To: Eric Wong <e@80x24.org>
Cc: meta@public-inbox.org
Subject: Re: [PATCH v2] Clarify Inline::C dependency (optional on Linux,
 required elsewhere)
In-Reply-To: <20230902185015.M198704@dcvr>
References: <20230830051045.330641-1-e@80x24.org>
 <20230830051045.330641-1-e@80x24.org>
 <20230830143409+0200.929541-stepnem@smrk.net>
 <20230830211849.M275594@dcvr>
 <20230831111152+0200.360729-stepnem@smrk.net>
 <20230831192650+0200.929387-stepnem@smrk.net>
 <20230901110903.M876537@dcvr> <20230902125449+0200.22309-stepnem@smrk.net>
 <20230902130741+0200.224663-stepnem@smrk.net>
 <20230902185015.M198704@dcvr>
User-Agent: Notmuch/0.37 (https://notmuchmail.org) Emacs/30.0.50
 (x86_64-pc-linux-gnu)
Date: Sat, 02 Sep 2023 21:08:25 +0200
Message-ID: <20230902210825+0200.747967-stepnem@smrk.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
List-Id: <meta.public-inbox.org>

On Sat, 02 Sep 2023 18:50:15 +0000
Eric Wong wrote:

> =C5=A0t=C4=9Bp=C3=A1n N=C4=9Bmec <stepnem@smrk.net> wrote:
>> -Numerous optional modules are likely to be useful as well:
>> +Numerous other modules are likely to be useful as well:
>
> What is the reasoning for this change?
> "optional" is an important point to state, IMHO.
> Using "other" is more ambiguous, I think.

We've now established that at least Inline::C is not optional on all
systems.  Is that really the only case?  (I mean, some of the modules
have "optional" again in their respective parentheticals: is that just
redundancy, or does it imply that the others are less optional?)  Even
if it _is_ the only case, isn't saying "optional" misleading?

>> @@ -76,8 +76,9 @@ Numerous optional modules are likely to be useful as w=
ell:
>>  - Inline::C                        deb: libinline-c-perl
>>                                     pkg: p5-Inline-C
>>                                     rpm: perl-Inline (or perl-Inline-C)
>> -                                   (speeds up process spawning on Linux,
>> -                                    see public-inbox-daemon(8))
>> +                                   (required for lei on *BSD; speeds up=
 process
>> +                                    spawning on Linux, see
>> +                                    public-inbox-daemon(8))
>
> I think breaking up the lines on punctuation improves readability:
>
>                                    (required for lei on *BSD;
>                                     speeds up process spawning on Linux,
>                                     see public-inbox-daemon(8))

That's much better, thank you!

> I particularly dislike having "process" and "spawning"
> being on separate lines.

Yeah, it's horrible, but somehow your sane version didn't occur to me...

Thanks,

  =C5=A0t=C4=9Bp=C3=A1n