Re: bracketed paste

[Yuri D'Elia <wavexx@thregr.org>]

On 16/07/15 07:19, Oliver Kiddle wrote:
> Yuri D'Elia wrote:
>>
>> Also, I realized sometimes a final newline was tricking me into thinking
>> that the command was already enter-ed to the shell (but of course, it
>> wasn't). Stripping any final newlines is an improvement.
> 
> Should we perhaps do this in the default widget? That is strip off the
> last character if it is a newline. With a default setup, it isn't
> actually possible to see the difference between the newline being
> inserted and the command being executed but doing nothing for a long
> time. In either case, the cursor position is the same.

I don't think that removing it only if it's the final character is
enough. A string like "\n " is also tricky to spot somehow.

I would say a better improvement would be to remove any trailing empty
lines. Something like /(\n\s*$)+/.

But then again, if you're pasting spaces, the cursor might also end-up
being exactly at the beginning of the new line.

It kind of depends on what are your expectations on paste. If you're
pasting spaces on purpose (for example, to concatenate more commands),
you kinda expect paste to be literal. I do this from time to time: paste
beginning from here, rest from there, or paste whitespaces in a literal
quote (yes!). Terminal-to-terminal pastes are often containing
intentional blanks and newlines. What brakes it is mostly paste from a
rich web page, where the selection is often aleatory.

I'm quite happy with the whitespace trimming on both ends. The fact that
I could do the same with the new widget is also good.

Although I'm not sure I would need to unquote the string before
stripping when a prefix argument is given: in that case my stripping
function would break, and I need to know if the argument was given or
not to perform the unquote/quote.

In that scenario, maybe a "paste_trimmed" style would be better. It
avoids the kludges, and it's obvious: either you want literal paste, or
you don't want excess whitespace around.