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

[Vincent Lefevre <vincent@vinc17.net>]

On 2016-05-13 04:06:45 -0700, Bart Schaefer wrote:
> 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.

I see. BTW, bracketed-paste-magic breaks the "undo": it clears
the whole line.

> 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.

OK. Since the only effect of bracketed-paste-magic I was seeing
was the url-quote-magic one, I thought that this was the equivalent
of url-quote-magic, but with paste instead of keys entered with the
keyboard.

So, the behavior I expect *on the buffer* seems to be the one with
backward-extend-paste (except that undo and paste highlighting are
broken).

> > 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.

Indeed, I've tried, and it works badly. The paste must be a single
complete URL and form a single argument.

> >> 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.

IMHO, the behavior should be similar to the case where the user enters
(non-control) characters one by one instead of pasting them.

Now, even url-quote-magic seems incomplete: if I start to type:

  echo $(echo http://foo

then a question mark, it is not quoted.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)