Re: bracketed paste - chopping trailing newlines

[Carsten Hey <carsten@debian.org>]

Hi,

in my previous mail I preferred an extended newline stripping variant.
I think this was wrong.

The proposed "strip a trailing \n only if it is a syntactic whitespace"
variant would solve all possible issues I wanted to solve by this in
a better way.  Even without this syntactic whitespace variant, I would
now prefer not to strip trailing newlines at all with highlighing by
default over my extended newline stripping variant.

This syntactic whitespace variant could be applied after pasting, before
the command gets added to the history, or not at all.  Without some
testing, I don't know which of those I would prefer.


* Bart Schaefer [2015-09-01 16:48 -0700]:
> On Aug 30, 10:25pm, Carsten Hey wrote:
> } > 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
>
> It was meant to do exactly what I described, and that's all.

Ok, then this was more than a prototype (with some definitions of this
word in mind).

If used with zsh 5.1, the below quoted part of the description does not
match the behaviour, i.e., a trailing newline is stripped, but you might
have intended it to be used with a zsh that has the newline stripping
commit reverted instead, and then, I think, it should match the
description:

| ...  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).

I should have tried the other part with only one trailing newline too.

> If there are corner cases that doesn't cover, ...

The highlighting also felt wrong somehow.

> ... are they worth the effort?

Only if they are not fixed by reverting the newline stripping and if you
consider this as reasonable alternative for default behaviour in the
next zsh release.

If someone wonders how if this behaviour different from the behaviour of
5.0.8 (not tested, but I don't see anything that could have broken
this), try for example pasting $'echo foo\recho bar'.

An other main paste feature, not running a pasted command without user
interaction, would be disabled by this (which makes it, for my private
setup, a good candidate for being activated if needed by some currently
unused function key).

Btw., I also think that highlighting is sufficient to alert the user
that no command is running - that it vanishes if a command runs makes
this pretty clear for the second time, and the first time the previously
unseen highlighing should catch the attention of the users and make them
check what happend.  zle -M ... seems to be a bit too verbose for
a default behaviour.


Regards
Carsten