Re: bracket-paste-magic adds backslashes inside a quoted string if URL is pasted ("regression" compared to pre-5.1 url-quote-magic)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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