From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20203 invoked by alias); 5 Jun 2015 14:35:17 -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: 35395 Received: (qmail 22505 invoked from network); 5 Jun 2015 14:35:16 -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.1 required=5.0 tests=BAYES_00,FSL_HELO_BARE_IP_2, RCVD_IN_DNSWL_LOW,RCVD_NUMERIC_HELO,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: Yuri D'Elia Subject: Re: bracketed paste mode in xterm and urxvt Date: Fri, 05 Jun 2015 16:35:02 +0200 Message-ID: References: <55677AF5.50709@thequod.de> <27004.1433345491@thecus.kiddle.eu> <3098.1433511607@thecus.kiddle.eu> 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.18 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 In-Reply-To: <3098.1433511607@thecus.kiddle.eu> 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.