From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18425 invoked by alias); 30 Aug 2015 20:25:35 -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: 36337 Received: (qmail 14748 invoked from network); 30 Aug 2015 20:25:33 -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,FSL_HELO_NON_FQDN_1 autolearn=ham autolearn_force=no version=3.4.0 Date: Sun, 30 Aug 2015 22:25:30 +0200 From: Carsten Hey To: zsh-workers@zsh.org Subject: Re: bracketed paste - chopping trailing newlines Message-ID: <20150830202530.GF30848@bosko.stateful.de> References: <20150829012452.GE30848@bosko.stateful.de> <150828220057.ZM14497@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150828220057.ZM14497@torch.brasslantern.com> User-Agent: Mutt/1.5.21 (2010-09-15) % fgrep 5.0.9 * bracketed-paste-magic:# Starting with zsh-5.0.9, ZLE began to recognize the "bracketed paste" url-quote-magic:# As of zsh-5.0.9, the following may also be necessary in order to apply Hi, to get the most intuitive behaviour possible the bracketed paste code would need to consider what the parser thinks about the current line. If we assume, that this information is not available, then, stripping a newline if the previous character is not a newline (even though I mentioned that I would prefer not stripping them) in combination with the described possible behaviour if a paste immediately follows an other one, might lead to the most intuitive behaviour that can be archived easily. * Bart Schaefer [2015-08-28 22:00 -0700]: > On Aug 29, 3:24am, Carsten Hey wrote: > } The other natural choice to enable distinguishing a running command from > } a paste is using zle_highlight. This could also avoid the need for the > } possibly unexpected newline stripping feature. > } > } An alternative to paste:standout is paste:underline. Given that this > } one does not suffer from similar possible problems as paste:standout, > > Hm, standout, boldface, and underline are all used already for different > defaults. Underline is for isearch, though, so I suppose it's quite > unlikely to clash with paste highlighting. I noticed that GNU screen does not support bracketed paste. Expecting average zsh users to know which zsh version they run and if they disabled bracketed paste might be reasonable, but also expecting them to know which of their terminals support bracketed paste seems to be a bit too much, given that many people only paste seldom. If it is thus not that unusual that users might not know if bracketed paste is currently enabled, then being able to distinguish between pastes and running commands in an obvious way by enabling highlighting by default seems to be more important to me. > } [...] I think, that a trailing newline should only > } be stripped if it does not immediately follow an other newline > > Another way to approach this would be for a trailing newline to actually > be taken as accept-line, provided that RBUFFER is empty. ... This is a very interesting idea and I might use a variant of it in my ~/.zshrc. I don't think that this would be adequate as default behaviour, though, since it breaks the assumption users could have that a pasted command never runs without being acknowledged first, but YMMV. > ... In contexts other than PS1, e.g., a here-document, this is > identical to keeping the trailing newline (except that the PS2 prompt > is repeated). > > Here's a way to try that on for size: I assume your prototype was not meant to handle all corner cases in a perfect way, but other than that, it's a good fit for my personal needs, thanks :) Regards Carsten