From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28010 invoked by alias); 19 May 2016 21:21:43 -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: 38521 Received: (qmail 24982 invoked from network); 19 May 2016 21:21:42 -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 autolearn=ham autolearn_force=no version=3.4.1 Date: Thu, 19 May 2016 21:14:58 +0000 From: Daniel Shahaf To: Bart Schaefer Cc: Zsh hackers list Subject: Re: bracket-paste-magic adds backslashes inside a quoted string if URL is pasted ("regression" compared to pre-5.1 url-quote-magic) Message-ID: <20160519211458.GD8007@tarsus.local2> References: <20160509141306.GA18211@cventin.lip.ens-lyon.fr> <160509084143.ZM13554@torch.brasslantern.com> <20160510085833.GA20332@cventin.lip.ens-lyon.fr> <160510125848.ZM1686@torch.brasslantern.com> <20160513092348.GB18186@zira.vinc17.org> <20160513222039.GA2425@tarsus.local2> <20160514030031.GA2530@tarsus.local2> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Bart Schaefer wrote on Sun, May 15, 2016 at 04:59:27 -0700: > On Fri, May 13, 2016 at 8:00 PM, Daniel Shahaf wrote: > > > > Asking the user to explicitly invoke from pre-redraw all plugins that > > need to be invoked from pre-redraw would be a compatibility / upgrades > > nightmare: whenever a plugin that previously didn't use pre-redraw would > > want to start using pre-redraw, all that plugin's end users would have > > to edit the Single Master Pre-Redraw Function in their .zshrc's, in > > lockstep with installing the updated plugin. This would simply not > > scale. > > > > What would scale is an interface similar to the one add-zsh-hook > > provides for non-zle hooks: an interface that allows an arbitrary number > > of registrations, where the various registrants — be they the user's > > .zshrc or plugins — need not know or care whether there are other > > registrants. > > I was never very happy with the built-in variables for lists of hooks, > particularly because they needed an externally-defined helper > (add-zsh-hook) to make them practical. I think add-zsh-hook could > have been written entirely in terms of the original precmd et al. > functions without the corresponding variables. > Fair enough. > Hence I also think that a plugin registry for the special zle hook > widgets ought to be implemented externally, and the plugins agree to > make use of it -- because if the plugins don't follow such a > convention then the user has to update .zshrc in lockstep with the > plugin installation anyway. I don't follow your reasoning: whether .zshrc needs to be updated manually is orthogonal to how the plugin hooks into zle. It is about the mechanism used by zsh to find and run the code that _installs_ the zle hook, not about whether said installation is done by directly calling builtins and defining specially-named shell functions or by calling some registrar function. (That is: even if a plugin foo uses a "plugin registry", the user would still need to run «echo 'autoload foo && foo' >> .zshrc».) I'm happy to keep this external, although if widgets shipped with zsh used this "external" plugin, it'd probably become de facto official. Cheers, Daniel > This convention could include allowing plugins to describe (or at > least suggest) the order in which their hook should be called.