Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: bracketed paste - chopping trailing newlines

Oliver Kiddle wrote on Tue, Sep 08, 2015 at 12:39:37 +0200:
> Bart wrote:
> > OK, so who is a normal user who doesn't follow this list?  A zsh user from
> > past versions who expects the paste to run magic-space and accept-line?
> > That clearly isn't what you mean, but I'd like to de-confuse them too.
> Not getting magic-space in the middle of a paste is fairly apparent. The
> same for intervening accept-lines because the prompt is not reprinted
> for each line. So in these cases a user expecting old behaviour would
> see that there has been a change and hopefully be pleasantly surprised
> rather than confused. A trailing newline is not so apparent. It seems
> like I'm just repeating myself on the rationale for the blank stripping;
> wasn't the case made adequately back in 35794?

Yes, I also feel I'm repeating myself.  I've already made my case a few
times.  I've also suggested fixes and implemented them.  I have been
trying to reach consensus, but so far haven't succeeded.  As you can
imagine, by now I'm rather frustrated.

Looking back over the threads, my RFE consisted of three parts:

1. Don't strip newlines at paste
2. Highlight pastes
3. Strip newlines at accept-line that immediately follows a paste

I think no one actually objected to (1), so I'll push it after the 5.1.1
tag, so we have the entire 5.1.2 release cycle to make tweaks.

I think all objections to (2) have been addressed, apart from the
question of whether to use standout or underline.  I think standout is
easier to spot and doesn't clash with zle_highlight[region]'s default
(because the user knows whether she just pasted or not), but I wouldn't
mind underline being the default, if that'll get us out of the impasse.

As to (3), I don't feel strongly about it.  If people don't want it in
the core, I'll just effect it in my dotfiles (as in 36429).

So, to summarize: I'll push the 0001 and 0002 patches from 36443 after
the 5.1.1 tag, and if we want to later change it to underline, we can.

I hope this thread will end soon :-)



> I'm all in favour of alternatives to the blank removal that address the
> original issue. Simply waiting until user expectations have adapted and
> is one alternative. Blank removal in accept-line is a quite separate
> notion.
> Daniel Shahaf wrote:
> > 3. Avoid saving trailing newlines into history.
> I'm no more keen on accept-line altering text before it goes into
> history than on bracketed-paste altering pasted text.
> Oliver

Messages sorted by: Reverse Date, Date, Thread, Author