From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8462 invoked from network); 24 Jun 2021 23:52:39 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 24 Jun 2021 23:52:39 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1624578759; b=VDZWMNifLX6FiNY6K/uxJE4Jd9m5is0gYdq7ZumhWqj6rVR/ZSR1hrohhUXccgV0mOAdMJkRyA hmmkTn+qHNnHvnuAyx2/C4OBYVg1blxsNtgAZnNR5WU1Jo5rN2Qa/7HOl+9bAzBaTivG+mn3Ew zH6no7gBDckHdMIan4wzI0jmKBIuSvv4IqhQ5tpwSDaOByYnCvyNnvdba1l5rr4QHqCIZXym4m QtYt0n1vUoq0++2EAUa1OFV1mRh1FPpE9tWU3iH0HIzBGdIwNIC36Sj09ob4yt6mMAd/4uPsT0 4pUPhGG7+lfhJOySXs3NFkIRwfapFOJgwwTRZ26F7tViQw==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (wout5-smtp.messagingengine.com) smtp.remote-ip=64.147.123.21; dkim=pass header.d=daniel.shahaf.name header.s=fm3 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm3 header.a=rsa-sha256; dmarc=none header.from=daniel.shahaf.name; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1624578759; bh=o5OKujDsOc+bU382tv0VWQsplgYPqkPlmWM6yme734g=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:DKIM-Signature: DKIM-Signature:DKIM-Signature; b=1QJTxMjTz8v4kdMTBcZtXm9mQ5O3dQtw2eNVo4PHGms5ebcwRNa+GeZSrV3EmMTti0T15LZqx8 Znj49zDUNpmODXytb0lfVPle0zopmZ8BOhr6EFeLr0UmGx8ZSlqNTu2aVtlLGoCBiy/ti5e14Q UjhocNUHvuoirMhJZWYybUNEM/qErENXXo6NxRPITjW37x4tEafxyNhOsMwWgV3IYENaLhK13G xuUfCFzDzKo/L/WxR8jOc6GZLQfq9jQxSeHhGBRjuMP2i8UELHxJAFrlYn/C1vx9o41/5YB0hE 1Q8ILrUxfm3BFNLpOkM5OE7J8ekACJ1gWqGRQDcty2yw3A==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:In-Reply-To:Content-Transfer-Encoding :Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID; bh=XWOoc16a1OjuXIVZ7ltLFa+2MBO/co3ugNrCeh9FXkM=; b=dPrTa4bKuvbRUScfaPKgW0MjJd yPegklte1zlR0OPARemadfN6mSfIMzLxqPDkCHZWhuWBWE/dPr96IsJCw/TQ3YQMcY7a3hzv3dXJ1 wYFo8ysIrG+QjZoAc45BQNONaKSURpz0d2FNfwdItFs6zfeGZbJvjYqJq2rg9Q40v1F5OloSA9Ygp AfD0QKgAhtZX2/52uAokUpdM8CA25GFR3dlRogef4sHE8UwLkX2fSsI4CNcjKigv1pUQ6liA/nr/0 VJQse3f4YJdgOzgarQ3JwFUjZmziqdeqvg+nTNA8IGMxp9qzgntfATdvDobgShnb5d0J4wVJl9f8k YU1PUGzg==; Received: from authenticated user by zero.zsh.org with local id 1lwZ9B-000HZV-VT; Thu, 24 Jun 2021 23:52:38 +0000 Authentication-Results: zsh.org; iprev=pass (wout5-smtp.messagingengine.com) smtp.remote-ip=64.147.123.21; dkim=pass header.d=daniel.shahaf.name header.s=fm3 header.a=rsa-sha256; dkim=pass header.d=messagingengine.com header.s=fm3 header.a=rsa-sha256; dmarc=none header.from=daniel.shahaf.name; arc=none Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:47655) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1lwZ8w-000HHx-IZ; Thu, 24 Jun 2021 23:52:24 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id BC09F3200583; Thu, 24 Jun 2021 19:52:19 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 24 Jun 2021 19:52:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:content-transfer-encoding :in-reply-to; s=fm3; bh=XWOoc16a1OjuXIVZ7ltLFa+2MBO/co3ugNrCeh9F XkM=; b=DiuA1Seu9Pp+3Q5rJTGt5sQP6+nck+O7X0aiBFHn5aFQYbnDYZE/OQ9T SUwoPcl1rHf9h+1ZyMWX+VV7ho0MvX/OqQ7pPRm1CS3n6ilpyxn8hvQlZDtwT/4E zeXyAYpbfi2ajAbpRCDeF7E8hmZ2sJ2MzS6OkdoGiOZ+U2mV9X2qr8+7R1ullNSz Vxofqfin749x5mNPpvohBy7kdf1IOSKLtwY5ZTwdZvO30zysiuuosgY+49ti+lcv PyjIFBAfHjhyllVg+K+nl9/bRnIqHv0KyJuTpITofvaJJdpbf0frSED/Vku58Gh6 KXdNrxpzqiafJ0Byjs8YfLA8Xs0dNw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=XWOoc16a1OjuXIVZ7ltLFa+2MBO/co3ugNrCeh9FX kM=; b=Tby7gP6jQNszA5ABsj0fHs6jaM2zso5s+meaxnSrQkH+4cGCHE+p0MYrj a5bR3gBF0qoVo8ujocWcUWUTO/5Ya0pL/za0krABEv0xUfxEtrvBrj6IgdcXSA3K ES5JokfF+/nIBxUIiV3/+mvL4Mz3ldOoU8zT4lzf4QuPEqi1SU9Gfbtu9p6HtTTq 9ATRET4x+zda+8bKbGHeyEj24wUZzf7QJmrlQKYwF6dCA8kLrJDUU86ZtmCvP3Rq g9dmuTmT62lOoPLu0tHF5j+QLIV3k9CmdKohWBPCHIB/5atC0gEYu+okDXmpfSoP Exy4364SfU/6eNeBaIXDgpbhtMlhQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeegiedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtugfgjggfsehtkedttddtredunecuhfhrohhmpeffrghn ihgvlhcuufhhrghhrghfuceougdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgvqe enucggtffrrghtthgvrhhnpeeltedugfeugeekjeefgfetffejhfdtfeejfefghffhkeev tdethedvtdefkeelheenucffohhmrghinhepshhouhhrtggvfhhorhhgvgdrihhopdgvvh gvrhihfihhvghrvgdriigvrhhonecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepugdrshesuggrnhhivghlrdhshhgrhhgrfhdrnhgrmhgv X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 24 Jun 2021 19:52:18 -0400 (EDT) Received: by tarpaulin.shahaf.local2 (Postfix, from userid 1005) id 4G9xkm4DCXz4fb; Thu, 24 Jun 2021 23:52:16 +0000 (UTC) Date: Thu, 24 Jun 2021 23:52:16 +0000 From: Daniel Shahaf To: Marlon Richert Cc: Zsh hackers list Subject: Re: Does add-zle-hook-widget violate the contract of ZLE hook widgets? Message-ID: <20210624235216.GA25615@tarpaulin.shahaf.local2> References: <9c56f50a-d061-4175-958a-6f89f6bae822@www.fastmail.com> <20210624183006.GA16386@tarpaulin.shahaf.local2> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Seq: 49122 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Marlon Richert wrote on Fri, Jun 25, 2021 at 00:48:16 +0300: > On Thu, Jun 24, 2021 at 9:30 PM Daniel Shahaf wrote: > > > > Marlon Richert wrote on Thu, Jun 24, 2021 at 13:34:00 +0300: > > > On Thu, Jun 24, 2021 at 1:06 PM Daniel Shahaf wrote: > > > > > > > > Marlon Richert wrote on Wed, 23 Jun 2021 20:30 +00:00: > > > > > foo implements a perfectly fine zle-line-init widget. It obeys the > > > > > contract laid out at > > > > > https://zsh.sourceforge.io/Doc/Release/Zsh-Line-Editor.html#Special-Widgets, > > > > > which says nothing about return values. > > > > > > > > That has two possible interpretations: > > > > > > > > - Hook functions may set $? however they want > > > > > > > > - Hook functions should set $? to zero on success and to non-zero > > > > otherwise > > > > > > > > In favour of the first interpretation is that the manual's language > > > > doesn't explicitly rule it out and compatibility with hook functions > > > > that predate add-zle-hook-widget and don't set $? as > > > > add-zle-hook-widget expects. > > > > > > > > In favour of the second interpretation is that those semantics are the > > > > default, ubiquitous, baked into the language's syntax, and extensible > > > > (same thing as "This bit must be zero" in wire protocol specifications). > > > > > > > > I'm voting for the second interpretation. > > > > > > > > I suppose we could've added something to NEWS/README when add-zle-hook-widget > > > > was introduced, if only because this is an interoperability issue (foo > > > > and bar may be have separate maintainers). > > > > > > I think this should be mentioned permanently in the manual, exactly > > > because we see foo and bar from separate maintainers in the wild. > > > > I'm ambivalent about this. > > > > On the one hand, as mentioned, "set $? correctly" is a ground rule that > > shouldn't need to be made explicit everywhere it matters. I don't want > > to create an expectation that where the manual _doesn't_ explicitly > > specify that $? should be set correctly, $?'s value doesn't matter. > > > > On the one hand, someone who uses «zle -N zle-line-init foo» may not be > > aware of a-z-h-w and of the fact that the return value does have an > > effect. > > > > In balance, I think I would rather see it documented globally that $? > > should always be set to zero/non-zero unless explicitly specified > > otherwise. Makes sense? > > That makes sense, but then, it should also be documented what that > actually means. If your function returns zero/non-zero, what is > expected to happen? Does this always happen? Or are there different > classes of functions with different results for zero/non-zero? > > I can already think of two examples that contradict each other: > * In hook functions, callee returning NON-zero causes the caller to > refrain from calling more functions. > * In completion functions, callee returning ZERO causes the caller to > refrain from calling more functions. > > Those two behave exactly opposite of each other. > > My point being, I think this is best spelled out everywhere. > Zero/non-zero don't always appear to mean the same thing between > caller and callee. Clearly it matters, but it doesn't appear to always > matter in the same way. > I think it's misleading to look at the "caller and callee" system. They aren't coupled. The caller is written to work with any callee that follows the standard return value semantics, and the callee is written to work with any caller that expects the standard return value semantics. Some callers have a list of callees; some don't. Some callers who have a list of callees will call them all; some will call them until the first success; some will call them until the first failure. The callee neither knows nor cares. The callee simply takes care to return non-zero whenever it fails, and zero whenever it succeeds. That's implied. What isn't implied is which semantics the caller follows. The caller (e.g., add-zsh-hook, add-zle-hook-widget) should document that. > > > > > Should that `|| return` be removed? > > > > No, because that would break the case of _deliberately_ returning non-zero > > > > from one a-z-h-w hook to prevent further a-z-h-w hooks from running. > > > > Granted, that's not a documented promise, but there's no reason to break > > > > it, either. > > > > > > For hooks added through azhw, yes. But hooks added through zle -N > > > zle- have no reason to expect that their return value has any > > > effect. > > > > > > > I did give some reasons in my previous reply; and compare how drivers > > should use their turn indicators even when they don't see anyone on the > > road. > > That's because it's convention everywhere that you signal in the > direction to which you turn. However, what convention we're supposed > to follow for return values in Zsh is not quite as clear. See my > contradictory examples above. > My point was that drivers signal even when there's no one else on the road. The analogy to that is that functions should return zero for success and non-zero otherwise even when they don't know what their caller would do with that. > > > How about if azhw would ignore the return value _only_ of any > > > pre-existing zle -N zle-X widget? For example, this part of the azhw > > > code could be modified to wrap the original widget function in a > > > function that always returns zero: > > > > At this point, given that the current behaviour has appeared in stable > > releases for 4.5 years now and is _a priori_ preferable, I think it's > > better to document the current behaviour and move on. So, basically, an > > addition to the incompatible changes section in README (for 5.9) that > > describes the change in 5.3. WDYT? > > I'm fine with that. That documentation needs to be findable, though, > from the docs for both zle -N zle-X and azhw. Perhaps. The manual and NEWS/README have different purposes.