Re: bracketed paste - chopping trailing newlines

[Carsten Hey <carsten@debian.org>]

* Oliver Kiddle [2015-09-06 15:51 +0200]:
> Daniel Shahaf wrote:
> > The behaviour is: (a) pastes are never executed until <Enter> is
> > pressed; (b) zle_highlight is set; ...

It is still an open question, or at least one without a clear consensus,
whether using paste:standout or paste:underline would be a more
reasonable choice if highlighting will be enabled by default.
I consider paste:standout to be a more natural choice, but there were
concerns regarding using it as default.  I have no clear preference for
any of these two options.


> > ... (c) newlines are removed only at <accept-line>.
>
> I really don't see the point of doing (c).

For example, if this is not done, and assuming the default configuration
using the emacs keymap, you'd have to press <up> three times to move two
entries back in history list after pasting and accepting a command with
a trailing newline.


> With a trailing newline, it is now hard to discern that the line hasn't
> been executed: the cursor advances to the next line whether the newline
> is accepted or inserted so without the stripping the user is left
> waiting until they lose patience.

This is a very intuitive way if users paste exactly one newline and know
that they did so.  Additional highlighting could further improve this
intuitiveness, but it is not necessary for this example.


If you paste a command with two trailing newlines into zsh 5.1 running
in an xterm, the result looks like this (an underline is used as
cursor):

% cp -a /data /mnt/foo
_

If you paste a command with one trailing newline into zsh 5.1 running in
a screen (the latest release, not the 5.x development branch), the
result looks like this:

% cp -a /data /mnt/foo
_

As you notice, both are indistinguishable, but only the first one shows
a running command, and the second one shows a paste waiting to be
accepted.


> I think that the default behaviour
> should cater to normal users who don't follow this list.

> I agree that the newline stripping isn't ideal but it seemed the best
> option for the short term.

I fully agree, and I consider 5.1 to be adequate for such a short term
solution.  5.1-test-1-1 is already tagged in git, and the long term
solution is still being discussed, thus it could not have been part of
a non-delayed 5.1.

For the next release, or at least the one following the next one, a long
term solution could be targeted.


> And it is possible to work around it with a custom widget.

I think we all agree that we are only discussing the default behaviour.


Regards
Carsten