From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1382 invoked by alias); 17 Jun 2016 05:20:38 -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: X-Seq: 38699 Received: (qmail 2261 invoked from network); 17 Jun 2016 05:20:35 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=Wj6IoET36Uy/nl3lY0Q1qruuI+pytgcAvUIMjqFAqLQ=; b=iUg7dPVoPHs0NCg0v0mM3RWuAkqaNsmGl2EOvA8VsvuvKWhUMp0aACO3rc4V7BXDT5 Q+jKWUHnxNdit1RFXYXLyCLacyfyCMqD+0md2AyPlGvSJGbWCLU4hKNWVwyNnBQL2f99 Rc8JEsSIvQQlYwEiwoIzW+NJJhmD9XnHXzArNZgAOJCF0kqPlAkh0XLYgPBnmyW3zicR NLMJtnbkz1YTuziNxrq5qxyiNtx+5aER+VzAezgtlCgdxaHDkCj/CnQ7mUsYnNry6N8x Uaq1qZ+u87K+tc8bYEmV3rv68CSofnkOFPt9l64NwKocm2+uSISghm6wuk/lHMb9xax3 JMeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=Wj6IoET36Uy/nl3lY0Q1qruuI+pytgcAvUIMjqFAqLQ=; b=cDfEmo5IRPyLDLltgP24b4j3naeQ8TUAtXpFHTk/Z6brDZFT8o4ycbPgrCwylRNVPe coSnjla3ARe1TIs6jR3hcXVGdjmm7RWbPEqaLEW+COAdcVcAOLITh4CzvyC2Ib8qThcC G2VVUKLTXSgBPfyNQZVSB4cJUitHFuFu43hvMrVtBD3h8VuGejBeNWxasZmjhXdATRzs 7FcjNNbkY/LvBNqVyx99cJ0ReqeXB7ijfhsu3X7HxaYXvzz5HbFrAtj6qgLRi0JoC2yf RkgzaZJJgKU+AB5nzpqE0bC9n6ZTyMvPPwiudNhYvbGWDE2T8AecO7zsUcANxtI6veLt UctQ== X-Gm-Message-State: ALyK8tL89Lag1DwQ812gEZ5bQsKW4FdOgjBlmg9agGdvpGROuupZ3ZVn5+6vJIGXegqz5Q== X-Received: by 10.98.15.212 with SMTP id 81mr341977pfp.110.1466140831582; Thu, 16 Jun 2016 22:20:31 -0700 (PDT) From: Bart Schaefer Message-Id: <160616222055.ZM27034@torch.brasslantern.com> Date: Thu, 16 Jun 2016 22:20:55 -0700 In-Reply-To: <20160615232447.GA29225@tarsus.local2> Comments: In reply to Daniel Shahaf "Re: [PATCH] add-zle-hook-widget" (Jun 15, 11:24pm) References: <160612184453.ZM11316@torch.brasslantern.com> <20160613085219.GA23148@tarsus.local2> <160614111054.ZM17893@torch.brasslantern.com> <20160615232447.GA29225@tarsus.local2> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: [PATCH] add-zle-hook-widget MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 15, 11:24pm, Daniel Shahaf wrote: } } Bart Schaefer wrote on Tue, Jun 14, 2016 at 11:10:54 -0700: } > Mostly I made that decision because add-zsh-hook explicitly declares } > that its values are arrays and displays their values with "typeset" } > if the -L option is passed. } } Then how about saying that registrations may only be added/removed } through calls to add-z-h-w [-d], without documenting how its storage } is implemented? > it seemed odd to expose this > detail in one case and hide it in the other. } > The whole ordering thing depends on the cooperation of whoever declared } > widgets A and B in the first place. Declarer(A) could as easily make } > capricious changes to his index as not provide it at all. } } Let's not assume the author of (A) is malicious. I'm not assuming malice, just inconsistency, or a well-meaning decision that (A) should come after (B) even though declarer(B) thinks exactly the opposite. } The question is whether the API enables the problem to happen, and } the answer is it does: permitting registrations that specify no index } means plugins _will_ register without specifying an index. I'm not convinced that's a problem; no index means "I don't care when this runs, and it shouldn't matter." If it turns out otherwise for some other widget, then that other widget merely has to delete the un-indexed widget and re-declare it with an index. I think this is better than the situation with add-zsh-hook where somebody has to be sure ALL the add-* calls are made in exactly the right sequence ... or else has to know the implementation and muck with it directly. } I strongly suspect that the releasing the current interface would be } a mistake: with the current interface, the majority of registrants will } specify no index, and then regitrants that _do_ wish to take advantage } of the ordering facility won't be able to. The choice of index numbers can't be made in a vaccuum, and maybe it can't even be made by anyone other than the user editing his .zshrc. In the previous example, declarer(B) has to be aware of widget (A) and know what index it uses in order to choose another index that comes after it; how does that differ from being aware of (A) and therefore asserting new indices for both? If (B) is NOT aware of (A) then what difference could it make what index declarer(A) chose? } So, what I think _will_ work is either of three options: drop indices } altogether (restoring parity with add-zsh-hook); declare "no index" as } equivalent to index == 42 (for some well-known value 42); make indices } mandatory. I don't have a preference among these three options. These all degenerate to the same problem in the right circumstances; e.g. what happens if (A) and (B) both have index 42 and then (C) wants to run *between* them? What you have convinced me is that in the absence of an explicit index there's some value in retaining the order in which the add-* calls were made, which the code as last pushed doesn't. } > I'm strongly of the opinion that this is the WRONG way to manipulate a } > non-special editor widget, and that the right way needs more help than } > this kind of facility can provide, and that I'm not going to attempt } > to explain all the details in this thread. } } You do not have to agree with me, but it is common for whoever states } a disagreeing opinion to give at least a brief glimpse of the technical } considerations underlying their different assessment. The gist is that these special widgets by definition do nothing unless user-defined, so there's no distinction between replacing the widget action and augmenting it. Non-special widgets each have an intended semantic, so there *is* that distinction, and *usually* it's desired to augment rather than replace. For special widgets it's reasonable to simply enumerate a list of actions; for non-special that's not good enough. } I have a 'zle -N zle-line-init' in my zshrc. The function gets } redefined. Yeah, I've concluded that for add-zsh-hook the hook widget name and the implementation function name can't be the same. } zle-keymap-select takes a non-empty argument list. (and is one of the } widgets handled by add-z-h-w) Good point. } > (I wonder why the widget is NOT parsed as an argument of the -N option, } > now that I think about it.) } } The -N option doesn't take an argument; the widget name is a positional } argument. (The optspec is "aAcCDfFgGIKlLmMNrRTUw" with no colon after } the 'N'.) Yes, I know that; rephrased: "I wonder why the optspec for bin_zle chose to place the widget name in a positional argument rather than make it an argument to -N, given that there are no other valid options that can be passed along with -N." } % autoload -U +X add-zle-hook-widget Oh. It doesn't work with +X, it only works with -X. That's because the file is designed to be "source"-able rather than "autoload +X"-able. I'm not sure there's a way to make it safe for all three of autoload +X, source, and kshautoload.