Re: edit-command-line, vim, and pasting

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

On 6 Dec, Elliott Cable wrote:
> > I'm not sure we can do anything more generalized than the following
> > patch to edit-command-line. Perhaps the zle builtin could have an option
> > to cover the situation but that doesn't help much because the function
> > would still need to invoke the builtin. What did you have in mind?
>
> Hm. How can I get your fix included into mainline? I don't want to try
> and maintain local changes on each of my machines, but
> `edit-command-line` is excellent, and I really want to be able to use
> it reliably!

I've now committed it.

Sorry, the issue wasn't really finalised because the question of a
more generalised solution was hanging over it and I don't have much
enthusiasm (or time just now) for that; nor am I convinced that it's a
good idea:

A zle builtin flag hides what it is going on which might lead someone
to toggle bracketed paste on and off several times. That doesn't
interact well with typeahead. I'm also reluctant because I'm not clear
on why stdin is closed. The documentation states that it prevents
external commands from unintentionally blocking ZLE but then why is
edit-command-line reopening it not a problem? By the way, if we want
to add a reference to the documentation, it should come there (under
"User-defined Widgets").

I barely dare mention this but the few functions that use read -k 
arguably suffer the same problem.

With regard to Yuri's suggestion that we should push for xterm/urxvt to
do base64 for security reasons, if I was going to reinvent the xterm
feature, I'd ditch the end sequence and put the length in the start
sequence. That makes typeahead handling easier if the output is split
across separate processes (or parts of a single process). Fundamentally
the security issue is that web browsers allow a seemingly innocuous
selection that is something else.

Oliver