From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25540 invoked by alias); 3 Jun 2015 20:45:32 -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: 35377 Received: (qmail 11 invoked from network); 3 Jun 2015 20:45:30 -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=-1.7 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=no autolearn_force=no version=3.4.0 X-Injected-Via-Gmane: http://gmane.org/ To: zsh-workers@zsh.org From: Stephane Chazelas Subject: Re: bracketed paste mode in xterm and urxvt Date: Wed, 3 Jun 2015 21:42:58 +0100 Message-ID: <20150603204258.GE4767@chaz.gmail.com> References: <55677AF5.50709@thequod.de> <27004.1433345491@thecus.kiddle.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 05448b1b.skybroadband.com Content-Disposition: inline In-Reply-To: <27004.1433345491@thecus.kiddle.eu> User-Agent: Mutt/1.5.21 (2010-09-15) 2015-06-03 17:31:31 +0200, Oliver Kiddle: > [ moved to -workers ] > > Yuri D'Elia wrote: > > On 05/28/2015 10:30 PM, Daniel Hahler wrote: > > > Apart from that I think that this (bracketed paste mode) should be > > > included in Zsh's and get maintained this way. Then it could also be > > > adjusted for vi-mode. > > > > I do agree that mainlining this would make a lot of sense, even as a > > setopt. Or at least provide the keymap/functions needed to enable it. > > I've been using bracketed paste for a while now and would also agree. > The question is in what form to provide it? Note that I posted an > alternative mechanism in workers/29898. The patch below is a port of > that to C. [...] Also note that where terminals don't filter out control characters, there's a potential problem in the way ^C is handled. zsh disables all signal keys but "intr". If the data to paste (which is written in one go to the master side of the pty by the terminal emulator) contains ^C, then a SIGINT will be sent to zsh and the data from the start of the paste up to ^C will not be available for reading (discarded by the line discipline, at least on Linux). So any bracketed paste solution cannot be safe unless either ^C is removed by the terminal emulator (like newer versions of xterm), or ISIG is disabled in the terminal line-discipline. So, for a truly safe paste, zsh should probably do the equivalent of a stty -isig. That can only be done *before* the paste, so that means isig must be turned off all the time (at least when bracketed paste is enabled). Not desirable as CTRL-C comes handy to stop lengthy processes by the shell. To sum-up, for a safe bracketed paste, you need either: - terminal emulator to filter out ^[ and ^C Or if the terminal doesn't filter out ^[ and ^C both: - a different paste mode than xterm's \e[200~\e[201~ which doesn't work as may contain \e[201~ (something like: insert-formatted("\033[202~%S~%s", CLIPBOARD,PRIMARY,CUT_BUFFER0) would do). - zsh to disable isig. Maybe a better approach would be to query the X selection for instance with xclip/xsel where available. That can also be integrated with the zsh kill ring. I once implemented a PoC around that idea together with mouse integration https://github.com/stephane-chazelas/misc-scripts/blob/master/mouse.zsh -- Stephane