From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13089 invoked by alias); 2 Jul 2016 03:55:18 -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: 38777 Received: (qmail 12994 invoked from network); 2 Jul 2016 03:55:16 -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=J87Xq3iSV+wemxoU+T/pejCzzKxXfWBUPvXjlMI1Ctc=; b=CKBo+yWV0imfw6oujxbjCsgpev0jINRdGR1qJwteHm3o9B8VPW7GHii6/0XTrjZrgI eUjXwgVUr3c+NBFpnnsnfqnA44JYXjhkoWM9HRlt9Twiali1SBd0eTsUP0y6OEoBhWyC 5iHZh0R245+svro48fpZK6QfVX+FtYMYFj0+u+/gaQXbSPycMh5jtgmXRf2eIeE4RSVC cLcX3iY/mfXbnPD4Afu/vAX7SDO/7eE5dNICGOcdu8t8Kc4mvpwyxmMlOMnw9VrN4KXq qEgjx+zjzowtHlbSs+YGcg6Xv995OJD9aAR5+zE2W91mX5gD1M6jQ9w6lbB8F/pHM4uf eg0A== 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=J87Xq3iSV+wemxoU+T/pejCzzKxXfWBUPvXjlMI1Ctc=; b=hkGp5a5ip4RdHBxkHLB06zqsnuoEi6aEazpwI81J1bilGh405RBniJujMhQqvY6oRW EOKFILE3uzRNY6F4KtTbDLsatYKcGgtr8/UIl6Lvz98kMgBmwrCaVt+ACtSvN5weO5WL WOdCzjaIc9URjHe4n0Ghm5ZiBVCAEe8gTRxAFhS2AJSrWMrbtaL5DFzEjIFRK42Ldo3k Yf1jFy3KYfNkFlT8ZhX361d9MCPkTmCE8VvOmLMg3b+GTRy/JPPisSsX3CbdBmo8YNMG KRLs/vZTh1phpMIgngXOEPW7CDj7sEla9TV8Nt8nGLK46Uwib55EijMyLr4qRtjL9hZ9 YuXw== X-Gm-Message-State: ALyK8tKb1+h69lhmEZXfP6X6K38LWJsunJF+IcVI94Segn2a/dJtOaaeWhXjRRaENVupaQ== X-Received: by 10.98.206.77 with SMTP id y74mr2785471pfg.55.1467431713068; Fri, 01 Jul 2016 20:55:13 -0700 (PDT) From: Bart Schaefer Message-Id: <160701131158.ZM9615@torch.brasslantern.com> Date: Fri, 1 Jul 2016 13:11:58 -0700 In-Reply-To: <20160621014130.GA17100@tarsus.local2> Comments: In reply to Daniel Shahaf "Re: [PATCH] add-zle-hook-widget" (Jun 21, 1:41am) References: <160612184453.ZM11316@torch.brasslantern.com> <20160613085219.GA23148@tarsus.local2> <160614111054.ZM17893@torch.brasslantern.com> <20160615232447.GA29225@tarsus.local2> <160616222055.ZM27034@torch.brasslantern.com> <20160621014130.GA17100@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 Delayed response. On Jun 21, 1:41am, Daniel Shahaf wrote: } Subject: Re: [PATCH] add-zle-hook-widget } } Bart Schaefer wrote on Thu, Jun 16, 2016 at 22:20:55 -0700: } > 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. } } Agreed, although there _is_ something to be said for the "or else" } alternative: it is a thin/KISS solution, "here's the explicit order } hooks will be called in, have a field day". You can't have it both ways -- either the implementation must be documented, which you objected to, or it has to be possible to do what's needed without knowing. } Perhaps we should ditch indexing and use topological sorting [tsort(1) } is in POSIX] instead: then we can let registrants specify "before:" and } "after:" clauses I don't think we want to get into the business of storing a partial orderting and attempting to resolve it to a total one. For one thing, more information arrives every time add-zsh-hook is called. Redo the whole tsort each time? } so B could do "add-zsh-hook zle-line-init B_hook before:A_hook" How does that differ from: } Having (B) unhook/rehook (A)'s hook sounds like a recipe for } hard-to-diagnose bugs. ?? It's just the internals heuristically doing the unhook/re-hook at B's behest, instead of B doing it explicitly. Still, there might be something. Just thinking aloud: Firstly, I chose the syntax "index:name" to allow multiple items to be added at once, but add-zsh-hook doesn't work that way so there's no longer any reason for add-zle-hook-widget to work that way. So let's make the syntax be add-zle-hook-widget HOOK WIDGETNAME [INDEX] instead of embedding the index in the widgetname. (This might be tricky/confusing given that the widget list would still need to be stored with each index attached.) Secondly, the index could be symbolic as you suggest; perhaps first, last, "before:otherwidget" and "after:otherwidget". The difference from a topological sort would be that before/after apply immediately, so if there is no "otherwidget" present yet, they mean nothing. You still have to call add-zle-hook-widget in some kind of sequence, but you don't have to know what index was assigned to otherwidget. Also, "otherwidget" should be a pattern. Thirdly, allow multiple symbolic indices, to cover "before:X after:Y". Try them until one fails, ignoring any that are meaningless. If all succeed, add the hook, else report error? One other thought -- it probably doesn't work to have a single sequence point for e.g. whether buffer modification happens. } I'm not sure whether this is simpler or more complicated than indices. Well, it sounds a lot more complicated to me, but it depends on whether you mean complicated for the user to figure out beforehand what index to use, or complicated for the shell to manage and the user to understand afterward why a particular order of execution was chosen. As tsort(1) itself says: > Note that for a given partial ordering, generally there is no unique > total ordering. That means the widgets might start running in different order after a new hook is added, for no reason the user is able to plainly see. I like the notion that a known total ordering can be imposed without having to express increasingly detailed partial orders for each new addition.