Re: bracketed paste

[Yuri D'Elia <wavexx@thregr.org>]

On 19/11/15 07:05, Bart Schaefer wrote:
> } https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787628
> } 
> } This made me think what I've written before in the bug report: what if
> 
> This would at the least require a different set of start/end sequences.
> (Not necessarily the ones sent from the app to the terminal to initiate
> and end the mode, but the ones sent by the terminal to indicate when a
> paste is happening.)  Whether you can find usages in the wild or not,
> the current pair of escapes already has different semantics.

Not a big problem IMHO.

> But I can't really muster enthusiasm for this idea.  It means that an
> app that doesn't want to play the game can't simply throw away the
> escapes and still receive sensible pasted content.  The consequences
> if the mode is unintentionally activated (or remains activated, as was
> happening with vim invoked from our edit-command-line widget) are at
> least as unpleasant for the app and arguably worse for the user.

Yes, it's something that we need to release in more cases, but I do not
expect so many weird cases popping up. Actually, I would expect the
majority to be found very soon due to the encoding being more invasive.

I'd "almost" want the proper bracketed mode being more invasive, as it
would clearly require support in the client, and require an active
interest as well.

> And it means building a base64 decoder into everything.  Yuck.

base64 is really the first thing that popped up in my mind, since it
would allow for transparent encoding of any binary also across a remote
pty. It's trivial to implement compared to more efficient encodings, and
popular enough you can just grab a prebuilt package most of the times.

But we can define our own encoding, really. Arguably, we could just
encode unwanted [8bit] sequences as an argument of a new control
sequence entirely. This would degrade much better, for example, but
deciding what gets encoded and what not would not be as clean as a flat
base64.

> In the vast majority of cases the only problematic characters that
> appear in a paste are line breaks.  Having bracketed-paste activated
> by default in zsh seems only to be causing more issues than it solved.  
> Having an extra keystroke to turn it on (and then automatically turn
> off when the "closing bracket" is seen) might have been a better plan.

For me this would be a step backwards. By fiddling with the widget I was
finally able to enable URL quoting only when pasting, I do whitespace
stripping as well, and in general I'm quite happy that I can
differentiate between the paste and typing.

In fact, I'd like the same behavior in vim, for example, so that I don't
have to enter/exit paste mode, and so that I can ensure a paste will not
exit paste mode itself.