From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1614 invoked by alias); 13 May 2016 11:06:49 -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: 38485 Received: (qmail 17299 invoked from network); 13 May 2016 11:06:47 -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=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=Ym0HXdBONjLd/Ki95/NHQmxH867xciZ7g/aTFKZUSyg=; b=e9AaicbVr3JzjjKEfHQn25m+56QaEUW3AT5dPRGgW16KEPo1wPmBCvK8ig3PrJ6fH0 1lxGbTJ+EOC6C3qd2oaCKKaq76lboQ6Mp06lMsWlGIMSdBmAx7Kp8tcoxWbaC8G3e3XO m3P5EMBtSu3P45kgZ2Wsq1TpKPL3ynW/Xlh6hnctFHY3vzqT6TUeuzBBWgL3p4VeZMQp 0D1Dxp7XVrCviqlzjElzRvNLPCpYAZnlbjzyPrT+iuyJ1gOkGbqhaF4mZt00qpq7Enio kL6QYE+Or7LPiDGHL21YQtKHZy7n3Q7DZAOkP1iB0jfiZW7U687WiV2/oE94CtF+C/0l n4Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=Ym0HXdBONjLd/Ki95/NHQmxH867xciZ7g/aTFKZUSyg=; b=UFYi5Brtp5k0xUGC1q7m6zwMXqJXcbomSYMPMaWN7KuF7cKFNxvQELxzWoTZc9QP8w 0AZontycTzz3iQEF3DV27Jm0gCtV2+itt6lkLdp6P7jUzEaQ3LMwxkse/sfsvZu7werJ 8EvNDV+dEoJraaHbmNTMLPmaxUrXgyvqjE9IcHnSxi2Z/rC3v1gYrBglqDhp1tZ8v/gH Yqz1Zk1zT4ILMkjN/tL9wCvclC3m8+H2w50JimP8ACSDxhvUGkx0kkv9OwzXHnyEBYlH aCMtpK1Ff6e055MxT1dIOH/frzA7OV0AwLSfRIpXaqx5s2A5fxh0KxK7j5sVNf0wU79z qqcg== X-Gm-Message-State: AOPr4FXhQjPfyb0BQniAYE7Y+FghPF4uEHx+1Otyxop1exsbne+rsdhdnVavWBr9931Q+7/sa++sw6rxv764Lw== MIME-Version: 1.0 X-Received: by 10.112.72.193 with SMTP id f1mr6427572lbv.114.1463137605168; Fri, 13 May 2016 04:06:45 -0700 (PDT) In-Reply-To: <20160513092348.GB18186@zira.vinc17.org> 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> Date: Fri, 13 May 2016 04:06:45 -0700 Message-ID: Subject: Re: bracket-paste-magic adds backslashes inside a quoted string if URL is pasted ("regression" compared to pre-5.1 url-quote-magic) From: Bart Schaefer To: Zsh hackers list Content-Type: text/plain; charset=UTF-8 On Fri, May 13, 2016 at 2:23 AM, Vincent Lefevre wrote: > On 2016-05-10 12:58:48 -0700, Bart Schaefer wrote: >> On May 10, 10:58am, Vincent Lefevre wrote: >> } >> } > We had quite a bit of discussion on related topics when bracketed-paste >> } > was added. The general idea is that a paste is treated as a unit, and >> } > the default behavior of bracketed-paste-magic is to restrict its action >> } > to remain "inside" that unit. >> } >> } I'm not sure what you call "unit" >> >> A single keystroke. A single widget event. As if the entire paste, no >> matter how large, is one indivisible object. > > But the main point is that there is a context. We're talking past each other a little bit here, I think. There are two entirely separate things happening here: (1) special handling of the paste event; (2) special handling of text that looks like URLs. The proponents of "bracketing" the paste event take the position that a paste is one indivisible action and should be handled as such. bracketed-paste is like self-insert except that "self" is the entire pasted text at once. Context is irrelevant. Further, treating the paste this way is expected to "protect" the user from any unexpected content such as control characters that might have side-effects, and also to make reverting the paste be a single "undo" step. This is in direct conflict with special handling of URLs (or any other kind of possibly-context-dependent action) where, by definition, there are side-effects from what would otherwise be ordinary input. Several choices have to be made in order to resolve this conflict. bracketed-paste-magic is designed to be a generalized paste handler that allows the user to specify what happens for each of those choices. Consequently the default behavior is to minimally extend the plain un-magical bracketed-paste, and the more magic you want the more incantations you must utter. I apologize if the use of -magic as a suffix here is confusing. It was not intended to imply a close connection between bracketed-paste-magic and url-quote-magic; it's more that both are inspired by the "magic-space" built-in widget. 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.) > Do you mean that instead of the zstyle > line, bracketed-paste-url-magic would do the work? No, quite the opposite. bracketed-paste-url-magic was written because its author felt that bracketed-paste-magic is too generalized, but he went far the other way: Context already on the line is entirely ignored, and nothing happens unless the entire paste looks like a single complete URL. > Does this replace > bracketed-paste-magic or should bracketed-paste-url-magic be used > in addition to bracketed-paste-magic? They're each intended as a bracketed-paste replacement, they don't work together. > bracketed-paste-url-magic is not described in the zsh man pages. We usually leave that up to the writer of the function. See comments at top of function source file itself. >> A third (so far unimplemented) approach would be to examine LBUFFER >> for an unbalanced quote mark and treat the paste accordingly, but >> what exactly does "accordingly" mean? Escape any quotes of the same >> type that are in the paste, or assume the user is intentionally >> pasting the closing quote? > > I would say: the same behavior as url-quote-magic. Again, I'm asking what might be done in the general case of someone using bracketed-paste-magic but not necessarily using url-quote-magic.