edit-command-line, vim, and pasting

edit-command-line, vim, and pasting

[Elliott Cable]

I've just set up my Zsh to allow me to use the `edit-command-line` widget:

    autoload -z edit-command-line && zle -N edit-command-line
    bindkey -M vicmd v edit-command-line

For some reason I can't puzzle out, though, `vim` *when invoked via
`edit-command-line`* goes haywire when I try to *paste* something,
even with `:set paste` enabled.

When I attempt to paste even a single character, my terminal-bell
signals a few times, and then *part* of whatever I attempted to paste
(usually sans the first few characters, or in some other way messed
up) is actually inserted into the document.

I can't verify precisely what character-sequence vim is receiving, but
it's something mangled; there's clearly a couple BELs in there, and
some ESCs (because I'm already in insert mode when I ⌘V, and
normal-mode commands get run; sometimes the contents of a vim buffer
are inserted at the beginning of the *actual* paste, for instance.)

It's not anything in my Vim configuration, because it occurs in the
same way even if I set `VISUAL="vim -u ''"`, preventing Vim from
loading any configuration at all. Strangely enough, however, while it
does continue to occur if I invoke a new `zsh` without configuration
(`zsh -f`), it *does not* if I indirect that sub-invocation via env …
even when manually keeping all of the environment: `env -i "$(env)"
zsh -f (what the hell does that imply?)

This doesn't occur, ever, outside Zsh; or, specifically, outside of
the `edit-command-line` mode. Does anybody have any ideas what could
be causing this?


⁓ ELLIOTTCABLE — fly safe.
  http://ell.io/tt

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

[Bart Schaefer]

On Nov 1, 10:37am, Elliott Cable wrote:
}
} For some reason I can't puzzle out, though, `vim` *when invoked via
} `edit-command-line`* goes haywire when I try to *paste* something,
} even with `:set paste` enabled.

This is almost certainly yet another unexpected knock-on effect of the
new bracketed-paste handling.  Bracketed-paste is enabled when entering
ZLE and not disabled until exiting from zle, so any widget that invokes
an external command is going to hand over control of the terminal with
bracketed-paste still in effect.   This will cause the terminal to
send a sequence beginning with ESC at the start of the paste, which
will mess with whether vim is in insert mode.

We need a generalized fix for this.  Oliver?

Meanwhile you might be able to get away with using the "pastetoggle"
setting.  Examples here:

http://vimdoc.sourceforge.net/htmldoc/options.html#%27pastetoggle%27

The {keys} to use are  ESC [ 2 0 0 ~  to start and  ESC [ 2 0 1 ~  to
end paste mode.

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

[Oliver Kiddle]

Bart wrote:
> This is almost certainly yet another unexpected knock-on effect of the
> new bracketed-paste handling.

Indeed.

> We need a generalized fix for this.  Oliver?

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?

This also changes the comments to suggest ! rather than v as the key for
edit-command-line (v overrides a default binding that was added since
edit-command-line was written: visual mode).

Oliver

diff --git a/Functions/Zle/edit-command-line b/Functions/Zle/edit-command-line
index 103a1c1..b814552 100644
--- a/Functions/Zle/edit-command-line
+++ b/Functions/Zle/edit-command-line
@@ -1,8 +1,8 @@
 # Edit the command line using your usual editor.
-# Binding this to 'v' in the vi command mode map,
+# Binding this to '!' in the vi command mode map,
 #   autoload -Uz edit-command-line
 #   zle -N edit-command-line
-#   bindkey -M vicmd v edit-command-line
+#   bindkey -M vicmd '!' edit-command-line
 # will give ksh-like behaviour for that key,
 # except that it will handle multi-line buffers properly.
 
@@ -10,7 +10,9 @@
   exec </dev/tty
 
   # Compute the cursor's position in bytes, not characters.
-  setopt localoptions nomultibyte
+  setopt localoptions nomultibyte noksharrays
+
+  (( $+zle_bracketed_paste )) && print -n $zle_bracketed_paste[2]
 
   # Open the editor, placing the cursor at the right place if we know how.
   local editor=${${VISUAL:-${EDITOR:-vi}}}
@@ -24,6 +26,8 @@
     (*) ${=editor} $1;;
   esac
 
+  (( $+zle_bracketed_paste )) && print -n $zle_bracketed_paste[1]
+
   # Replace the buffer with the editor output.
   print -Rz - "$(<$1)" 
 } =(<<<"$PREBUFFER$BUFFER")

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

[Elliott Cable]

On Mon, Nov 2, 2015 at 5:16 AM, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> Bart wrote:
>> This is almost certainly yet another unexpected knock-on effect of the
>> new bracketed-paste handling.
>
> Indeed.
>
>> We need a generalized fix for this.  Oliver?
>
> 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?
>
> This also changes the comments to suggest ! rather than v as the key for
> edit-command-line (v overrides a default binding that was added since
> edit-command-line was written: visual mode).

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!


⁓ ELLIOTTCABLE — fly safe.
  http://ell.io/tt

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

[Bart Schaefer]

On Dec 6,  9:01pm, Elliott Cable wrote:
} 
} Hm. How can I get [Oliver's] fix included into mainline? I don't want to
} try and maintain local changes on each of my machines

Oops, I didn't notice that Oliver had never pushed his change, and I
guess Peter didn't notice either.  There's no reason it shouldn't be
included.

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

[Oliver Kiddle]

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