From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3731 invoked by alias); 1 Sep 2015 23:44:54 -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: 36390 Received: (qmail 29789 invoked from network); 1 Sep 2015 23:44:54 -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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=0kMNrNHcv9K6DeCTpHwprklKAf+E0nrQPieD81kt84Y=; b=UPZdisPiOGRGc9ASzN1bA5kaYaMxsr7MeMa5P2IZTMhSK492u3U5CmpXL66+qdlc2g OEXfwcUN7xy/H1QqA2FUKgNsmp1ybPEGVdzyLqAkV5rytibuVcZ7UyawaPdi0P+ryes2 FJO30+XMzqFYN9p42+joGUbHMut+FdLMmn/iE7G7jfbj2EzjwxVhZvEh33EFjzpTckwM NLC3efQ/RxymqPsROckpQGrJODwaRg0BCmTvSGyc9Na+VMJD+zXPncaQtRqBCZXMEXgh ry0O71vbhKCO3VCU7EnwIyeSLTpDUqeIutfKO3+X8TtcYYNOZJFt+WnCJ1cl4v6ERQob Qijw== X-Gm-Message-State: ALoCoQmHfzM0ZAFvQOqSCv5ml8iARagljK+vFphR05BQc7tCymbwTKwv4+L3njQhI6IDh7GzjVa2 X-Received: by 10.182.240.135 with SMTP id wa7mr19725605obc.63.1441151092915; Tue, 01 Sep 2015 16:44:52 -0700 (PDT) From: Bart Schaefer Message-Id: <150901164448.ZM2469@torch.brasslantern.com> Date: Tue, 1 Sep 2015 16:44:48 -0700 In-Reply-To: <20150831054744.GB1992@tarsus.local2> Comments: In reply to Daniel Shahaf "Re: bracketed paste - chopping trailing newlines" (Aug 31, 5:47am) References: <20150829012452.GE30848@bosko.stateful.de> <150828220057.ZM14497@torch.brasslantern.com> <20150830202530.GF30848@bosko.stateful.de> <20150831054744.GB1992@tarsus.local2> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: bracketed paste - chopping trailing newlines MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Aug 31, 5:47am, Daniel Shahaf wrote: } } So, to clarify, you are proposing: } } - A trailing newline will be stripped if preceded by a non-newline and } RBUFFER is not empty... I think stripped if RBUFFER *is* empty, rather than not, because if RBUFFER is left sitting there not empty then it's obvious that the paste did not result in a command line being accepted. } - but will be re-added if immediately followed by another paste. } } I don't like the sound of this, for several reasons: } } - The second clause constitutes state: f and } behave differently. I think state should be minimized. I agree. } As I've stated in other threads, my preferred option is to simply never } munge the user data at all, to minimize surprising behaviour and } maximize compatibility with other places that accept pastes. Of course the problem is that "least surprise" for a current user of zsh is for the newlines to be accept-line, whereas for a person expecting the behavior of a text editor the newlines should just be inserted. My suggestion of accept-line for a final newline only when RBUFFER is empty was meant as the least objectionable hybrid of the two. } The problem of user not realizing the command hasn't started to run } could be solved by having zle_highlight=(paste:...) and/or a 'zle -M' } message by default. On further reflection I don't think highlighting the paste is sufficient to solve this. Yes, it lets you know that a paste has occurred, but it doesn't help with realizing that a paste doesn't result in accept-line if you aren't already familiar with that. } We could even make strip the final newline for cosmetic } reasons if it had been inserted by a paste and is syntactically } whitespace. I find myself ambivalent about that. } Is there any other place accepting pastes that removes the final } newline? Everywhere I can think of just pastes the final newline if it } was part of the copied text. This is also considered by my hybrid suggestion -- the newline is not removed; it is part of the paste. It just means something different at the end of the line (it means what a newline usually means at the end of a line).