From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16999 invoked by alias); 18 Nov 2015 20:14:53 -0000 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-Seq: 37146 Received: (qmail 5849 invoked from network); 18 Nov 2015 20:14:51 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,RCVD_NUMERIC_HELO, T_FSL_HELO_BARE_IP_2 autolearn=no autolearn_force=no version=3.4.0 X-Injected-Via-Gmane: http://gmane.org/ To: zsh-workers@zsh.org From: Yuri D'Elia Subject: bracketed paste Date: Wed, 18 Nov 2015 20:57:14 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 193.106.183.2 X-Mozilla-News-Host: news://news.gmane.org:119 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Icedove/42.0 If you remember, I sent a patch for urxvt and bracketed paste in Debian a while ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787628 I now realized that we could avoid all the escaping madness if we re-define what bracketed paste should do for us. I briefly checked and found no use in the wild of bracketed paste (scanning for the escapes in google and github). This made me think what I've written before in the bug report: what if the terminal just encodes into base64 the block to be pasted? What we'd need to just is just wait for the end sequence, decode the block, and we have no other issues with break processing. It would even allow to send binary content in the way (d&d in the terminal, who-ho!). Heck, I'll write a patch to xterm myself if I'd need to push this through.