(Now fixed differently by commit 0e6d693d, which mainly fixes bug #54950.)

Bug #54950 has been unduplicated from this bug.  That bug is about undoing the pasted insertion as a whole, not about temporarily switching off auto-indent and hard-wrapping.

The request in bug #57527 is in fact a (more limited) duplicate of this one.

Bug #54950 has been marked as a duplicate of this request.

Please consider supporting bracketed paste mode (http://invisible-island.net/xterm/ctlseqs/ctlseqs.html#Bracketed%20Paste%20Mode), supported by many terminals.

Enable by outputting ^[[2004h after switching to the alternate screen, disable by ^[[2004l before switching back.

If any user data is pasted (by mouse or terminal's shortcut keys or meny entry), rather than typed in from the keyboard, it will be surrounded by ^[[200~ and ^[[201~.

The desired behavior is to turn off word wrapping and auto indentation for pasted data; perhaps also turn off tab->spaces conversion. So that when e.g. source code is pasted, it won't get that well-known ever-increasing indentation.

The current code around get_escape_seq_kbinput() expects that if there's an escape sequence in the input buffer then there's no data following it, or it gets dropped. Detecting the incoming escapes near "F9 on VT220/VT320/Linux console/xterm/rxvt/Eterm" is easy but then unfortunately the actual pasted data gets dropped. This would require infrastructure change to keep and later process the non-consumed characters. That would be a good change anyways since the current design looks fragile. (I'm really not sure that multiple layers of terminal multiplexers, network connections, whatnot cannot combine two keypresses into a single read() call which is now handled incorrectly.)