Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
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: <CAH+w=7YYkto7u1WNcfmTs30o1wVGF4VRwnKmJtFz=5K4iLLp5A@mail.gmail.com>
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 <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Content-Type: text/plain; charset=UTF-8
X-Seq: zsh-workers 38485

On Fri, May 13, 2016 at 2:23 AM, Vincent Lefevre <vincent@vinc17.net> 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.

