Re: bracketed paste mode in xterm and urxvt

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

On 06/05/2015 03:40 PM, Oliver Kiddle wrote:
> Unfortunately not. As Stephane indicated, the string is written in one
> go. The terminal driver sees and handles the interrupt character before
> zsh has had the chance to interpret the start sequence. It's a feature
> that an interrupt doesn't rely on the user program having emptied the
> input buffer. It might be possible to do something from a clever SIGINT

What if the terminal itself turns off BREAK processing during paste?

> handler but I doubt that could be especially reliable. I think I'd
> rather have xterm/urxvt strip ^C (plus a few others) and know that I
> shouldn't expect pasting to be safe if I use something weird. Unless
> someone has some other ideas?

I'd rather not go down the xterm route... they've implemented a full
character filtering facility in there. Which I guess is ok, since this
will handle pastes for applications without any bracketing support.. but
I find it to be tacked-on fix.

> The important thing is that outputting \e[?2004h is harmless. Every

Putty also eats it by the way. If that's the case for all terminals, I
would just enabled it by default.

>> emacs disables the transient selection when pasting (which is inserted
>> on the current cursor position). For vi I'm not sure what I would
>> like... maybe the same. You have to enter insert mode normally, so it
>> would make it identical in behavior. Maybe gvim is different?
> 
> Replacing the selection is probably the most useful thing. Trying
> editors like gedit and nedit, pasting the secondary selection will
> replace the currently highlighted selection. GUI emacs is a bit the
> odd-one-out, not even grabbing the X selection but it is perhaps trying
> to be compatble with emacs run from a tty by default. A p command in vim
> does replace the selection while a middle-mouse paste uses the mouse
> position which isn't comparable.

I'm ambivalent to that. Replacing the selection seems pretty sound to me.