From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17462 invoked by alias); 14 May 2016 03:11: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: 38489 Received: (qmail 16868 invoked from network); 14 May 2016 03:11:41 -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-sha1; c=relaxed/relaxed; d= daniel.shahaf.name; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=uwpkDXgsQb/j3XDB Bzna7Wzd1c0=; b=hbkEx1v4GQAlsCZuzJVfUzo/rcCsfX2z3ngn39Me79wxe5Kt xWyQFsii17p8j8eaS5l3Icbjivwl5mxP7+E+rJ/C968dwzGIW9/zPqIWE7r/gaQy Uc6xlvRNHL7Nh8CsDIk5+Vlc0AlXinqfFE63vGiLY25odnKfYLPceGwhIxA= DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc:x-sasl-enc; s=smtpout; bh=uwpkDXgsQb/j3XD BBzna7Wzd1c0=; b=Ypv5mtIjMyBfe8zAGzTkb+wgdAuXqGt2YvpBpxep0NNzd2/ FMJUZ6aknUKmbQ4YPbr8R3SzVrxF2CFn/WRy1Vfx92VboI8Rt6Yd857BdG1Wcfvm RaL6tKEvUqjUHBekUzlH+v9/2XJWyOt6ETRXExAKD+w/AChwgKhKHezIJ7OA= X-Sasl-enc: gofefVHAZvOXyLTxTTjVNUDcsKSmimOEH8elGy1rNWIx 1463194840 Date: Sat, 14 May 2016 03:00:35 +0000 From: Daniel Shahaf To: Mikael Magnusson 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: <20160514030031.GA2530@tarsus.local2> References: <20160506205309.GY5029@sym.noone.org> <160508115026.ZM10022@torch.brasslantern.com> <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> 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.21 (2010-09-15) Mikael Magnusson wrote on Sat, May 14, 2016 at 03:33:46 +0200: > On Sat, May 14, 2016 at 12:20 AM, Daniel Shahaf wrote: > > Bart Schaefer wrote on Fri, May 13, 2016 at 04:06:45 -0700: > >> Stepping outside the box a little here -- when url-quote-magic was > >> written there was no such thing as the zle-line-pre-redraw hook. It > >> might be that a better approach would be to examine the entire buffer > >> in that hook after the paste has finished and apply the quoting > >> retroactively, rather than to do it character by character during the > >> paste. (On the other hand zle-line-pre-redraw is thoroughly co-opted > >> by popular plugins like zsh-syntax-highlighting.) > > > > So perhaps it's time to permit registering multiple functions to be > > invoked at pre-redraw, as proposed in 37639? This way, z-sy-h and > > url-quote-magic could each register a pre-redraw hook function. > > > > zle-line-pre-redraw has not yet been released: its interface can be > > changed arbitrarily. z-sy-h will be updated to use whatever interface > > zsh-5.3 will be released with. > > It's already possible to do > > zle-line-pre-redraw() { > whatever code > other code > z-sy-h-hook > yet more code > } > > Surely there has to be some limit to how lazy a user can be? > You're assuming the user knows what is all the code that needs to be run from pre-redraw. That need not be the case: the user may have N plugins and not know which ones of them use pre-redraw, since the use of pre-redraw by a given plugin might be an implementation detail of that plugin. 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. z-sy-h uses add-zsh-hook, but I doubt many users of z-sy-h even know that add-zsh-hook exists. I'd like the same to be true regarding pre-redraw. > Also, if multiple things register for this automatically, it feels > pretty likely more than one of them will be trying to do highlighting > and then things will be wonky. And if you modify the buffer in one of > them like in the GP example, the order _definitely_ matters or you > will have highlights in the wrong place, so the user will have to > intervene in that case. If "plugins" are automatically registering > your more generic hook interface, it is very difficult for the user to > arrange for the order to be correct. > Yes, if one pre-redraw hook modifies the buffer and the other updates $region_highlight, then they should run in this order. How do you propose that this be achieved? I think there are two ways: either (1) have plugins document their ordering requirements, and leave it to the user to 'autoload X && X' the plugins in a valid order; or (2) extend the widgets/hooks API so plugins can tell zle what relative order to run them in. Approach (1) is what z-sy-h uses today under zsh≤5.2 (which of course lacks zle-line-pre-redraw, but still has a problem analogous to this "inter-plugin hook ordering" problem). > This has a weak NAK from me. > > -- > Mikael Magnusson I respect your opinion, but I wish you would suggest an alternative. As I said, asking the user to invoke all his plugins from pre-redraw wouldn't scale. Cheers, Daniel (offline for the next few days)