Re: bracketed paste - chopping trailing newlines

[Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>]

Carsten Hey wrote on Sun, Aug 30, 2015 at 22:25:30 +0200:
> 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.
> 

So, to clarify, you are proposing:

- A trailing newline will be stripped if preceded by a non-newline and
  RBUFFER is not empty...
- 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: <paste>f<backspace><paste> and
  <paste><paste> behave differently.  I think state should be minimized.

- This particular state may cause a \n byte to be added at the _start_
  of the paste, which is an area I never look at: after I do a paste, my
  eyes are on the cursor, at the end of the paste.  So I fear this \n
  might be added without the user noticing it.  This has the potential
  to change the command-line's meaning.

- I think designs should have as few rules and exceptions as possible.
  Saying "Newlines will be stripped if X and Y, unless some third
  condition Z trumps" raises my mental alarm bells, due to the number of
  involved conditions.  (Especially when this is the initial draft of
  a design, rather than complexity that had developed organically over
  time.)

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

We could even make <accept-line> strip the final newline for cosmetic
reasons if it had been inserted by a paste and is syntactically
whitespace.  (The user would know the command has started running
because the pasted text will cease to be highlighted.)

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.

Cheers,

Daniel

> 
> * 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