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-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.1 Date: Fri, 13 May 2016 14:19:32 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org 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: <20160513121932.GA11181@zira.vinc17.org> Mail-Followup-To: zsh-workers@zsh.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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.6.1-6650-vl-r88942 (2016-05-12) X-Seq: zsh-workers 38486 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 - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)