Re: bracketed paste mode in xterm and urxvt

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Yuri D'Elia wrote:
> Actually, with this, couldn't we just disable isig while inserting the
> characters?

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

> > etc (I actually append the strings to PS1/PS2/POSTEDIT). It'd certainly
> > possible to add a setopt option to zsh to automatically output the
> > enable/disable strings for bracketed paste. Testing a few ancient
> > terminals (xterm and dtterm on Solaris 10), they seem to have no ill
> > effect. Perhaps it'd be better to apply some sort of heuristics based on
> > terminfo, however. Any thoughts on this?
> 
> I guess we can't use terminfo has no feature for this, right?

Not directly but we might discern some indication from it as to whether
it will regard the sequence as being an escape sequence.

The important thing is that outputting \e[?2004h is harmless. Every
terminal I've tried absorbs the string rather than printing some or all
of it so they presumably recognise \e[? four digit number h as being an
unknown escape sequence. Barring it having some other meaning, that's
all we need. Taking the output of this:
  printf '%s %q\n' ${(kv)terminfo[(R)*[0-9](#c4)[hl]]}
Shows smcup and rmcup as containing that pattern for xterm, urxvt and
screen as $TERM. libvte based things use "xterm" for $TERM. Does anyone
know of any other terminal that may be relevant, perhaps on a mobile
phone? What about putty?

> > What behaviour would you want in vi-mode? What about with the region
> > active? Replacing the region might make sense but isn't really what
> > emacs or vim do.
> 
> 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.

Oliver