From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 9b97bd2d for ; Tue, 17 Dec 2019 10:04:02 +0000 (UTC) Received: (qmail 7636 invoked by alias); 17 Dec 2019 10:03:57 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 45070 Received: (qmail 23756 invoked by uid 1010); 17 Dec 2019 10:03:57 -0000 X-Qmail-Scanner-Diagnostics: from wout1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.1/25663. spamassassin: 3.4.2. Clear:RC:0(64.147.123.24):SA:0(-1.9/5.0):. Processed in 2.733343 secs); 17 Dec 2019 10:03:57 -0000 X-Envelope-From: danielsh@apache.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: softfail (ns1.primenet.com.au: transitioning SPF record at amazonses.com does not designate 64.147.123.24 as permitted sender) X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvddtjedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdffrghnihgvlhcuufhhrghhrghffdcuoegurghnihgv lhhshhesrghprggthhgvrdhorhhgqeenucffohhmrghinhepfihikhhtihhonhgrrhihrd horhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegurghnihgvlhhshhesrghprggthhgv rdhorhhgnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-689-g5a57b82-fmstable-20191216v1 Mime-Version: 1.0 Message-Id: <0ecc07ce-4a29-4057-9c50-eb7151648b4a@www.fastmail.com> In-Reply-To: References: <20191217044607.31389-1-danielsh@apache.org> <4EC07132-46B8-4DD5-997C-858DC48DA29A@dana.is> <20191217073211.sb3m6dws2qixxyww@tarpaulin.shahaf.local2> <1FE80704-6C67-4B21-B995-4D474EB1ADFA@dana.is> Date: Tue, 17 Dec 2019 10:02:50 +0000 From: "Daniel Shahaf" To: zsh-workers@zsh.org Subject: =?UTF-8?Q?Re:_[PATCH]_internal:_Add_symbolic_names_to_possible_values_of?= =?UTF-8?Q?_zexit()'s_"from=5Fwhere"_parameter._No_functional_change.?= Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Mikael Magnusson wrote on Tue, 17 Dec 2019 09:46 +00:00: > On 12/17/19, dana wrote: > > On 17 Dec 2019, at 01:51, Daniel Shahaf wrote:= > >> It's not a mistake. "which" refers to "zexit()'s second parameter"= , and > >> is the direct object of the verb "see". It's a set phrase =E2=80=94= probably > >> began as a translation of . > > > > Oh, somehow i had never seen it written like that. Just my ignorance= then, > > sorry for the noise >=20 > I also have never seen it, and it seems to add no information to the > sentence either (I already know that following references is an > option). Remove to reduce confusion for readers? I wrote it deliberately, since I felt that documenting an enum type as "This is the type of the 2nd parameter to some_func()" wouldn't be best practice either. The "which see" addendum was intended to convey: "Yes,= this docstring doesn't tell you all of the information a docstring is expected to convey; instead, that information is behind the given pointer". However, I don't feel strongly about it. Whatever people prefer works f= or me.