Shift-Insert overwrites ZLE CUTBUFFER

Shift-Insert overwrites ZLE CUTBUFFER

[lolilolicon]

I use Shift-Insert to paste the X PRIMARY selection in terminal.
But when I use Shift-Insert, the ZLE CUTBUFFER is also overwritten.
Is there a way to disable this?

Example, with cursor at the end of line,

% foo
^W kills "foo"
^Y yanks "foo", as expected
% foo
Shift-Insert pastes "bar", content of PRIMARY selection
% foobar
^Y yanks "bar", instead of "foo", unexpected!
% foobarbar

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Bart Schaefer]

On Oct 25,  8:46pm, lolilolicon wrote:
}
} I use Shift-Insert to paste the X PRIMARY selection in terminal.
} But when I use Shift-Insert, the ZLE CUTBUFFER is also overwritten.
} Is there a way to disable this?

This is a side-effect of the "bracketed paste mode" feature that was
added about a year ago.

The previous contents of the cutbuffer are pushed onto the kill ring,
so you can retrieve it by following <^Y> with <\M-y> (or <ESC y>).

There's currently no easy way to change the cutbuffer behavior without
disabling the rest of the bracketed-paste behavior.

Re: Shift-Insert overwrites ZLE CUTBUFFER

[lolilolicon]

On Wed, Oct 26, 2016 at 12:12 AM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Oct 25,  8:46pm, lolilolicon wrote:
> }
> } I use Shift-Insert to paste the X PRIMARY selection in terminal.
> } But when I use Shift-Insert, the ZLE CUTBUFFER is also overwritten.
> } Is there a way to disable this?
>
> This is a side-effect of the "bracketed paste mode" feature that was
> added about a year ago.

Oh yes bracketed-paste, that is a good feature.

>
> The previous contents of the cutbuffer are pushed onto the kill ring,
> so you can retrieve it by following <^Y> with <\M-y> (or <ESC y>).

Thank you for the tip!

>
> There's currently no easy way to change the cutbuffer behavior without
> disabling the rest of the bracketed-paste behavior.

That's a shame.
Is it technically difficult to do? Would there be an issue if zsh just
popped the killring automatically?

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Bart Schaefer]

On Oct 26, 12:28am, lolilolicon wrote:
} Subject: Re: Shift-Insert overwrites ZLE CUTBUFFER
}
} On Wed, Oct 26, 2016 at 12:12 AM, Bart Schaefer
} <schaefer@brasslantern.com> wrote:
} > There's currently no easy way to change the cutbuffer behavior without
} > disabling the rest of the bracketed-paste behavior.
} 
} That's a shame.
} Is it technically difficult to do? Would there be an issue if zsh just
} popped the killring automatically?

What I mean is that it's not easy to do from shell code.  In the source
code obviously the implementation is deliberately pushing the kill ring,
so it wouldn't be technically difficult to *not* do so, but that would
mean reversing an earlier design decision.

Something like this sort of works:

  my-bracketed-paste {
    zle .bracketed-paste "$@" && {
      local pasted=$CUTBUFFER
      # Swap the top two killed items to fake out ^Y
      CUTBUFFER=$killring[1]
      killring[1]=$pasted
    }
  }
  zle -N bracketed-paste my-bracketed-paste

But I wouldn't have called that an "easy way".

Various other approaches involving saving/restoring CUTBUFFER and killring
are also possible.

Re: Shift-Insert overwrites ZLE CUTBUFFER

[lolilolicon]

On Thu, Oct 27, 2016 at 12:01 AM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> What I mean is that it's not easy to do from shell code.  In the source
> code obviously the implementation is deliberately pushing the kill ring,
> so it wouldn't be technically difficult to *not* do so, but that would
> mean reversing an earlier design decision.

I assumed the kill ring was used for implementation convenience.
If this was a deliberate design decision, I don't understand how this
is desirable to the user.
This doesn't seem to be documented, so I think it's OK to change it.

>
> Something like this sort of works:
>
>   my-bracketed-paste {
>     zle .bracketed-paste "$@" && {
>       local pasted=$CUTBUFFER
>       # Swap the top two killed items to fake out ^Y
>       CUTBUFFER=$killring[1]
>       killring[1]=$pasted
>     }
>   }
>   zle -N bracketed-paste my-bracketed-paste
>
> But I wouldn't have called that an "easy way".

Nice, thanks for showing me!

>
> Various other approaches involving saving/restoring CUTBUFFER and killring
> are also possible.

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Mikael Magnusson]

On Wed, Oct 26, 2016 at 6:01 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Oct 26, 12:28am, lolilolicon wrote:
> } Subject: Re: Shift-Insert overwrites ZLE CUTBUFFER
> }
> } On Wed, Oct 26, 2016 at 12:12 AM, Bart Schaefer
> } <schaefer@brasslantern.com> wrote:
> } > There's currently no easy way to change the cutbuffer behavior without
> } > disabling the rest of the bracketed-paste behavior.
> }
> } That's a shame.
> } Is it technically difficult to do? Would there be an issue if zsh just
> } popped the killring automatically?
>
> What I mean is that it's not easy to do from shell code.  In the source
> code obviously the implementation is deliberately pushing the kill ring,
> so it wouldn't be technically difficult to *not* do so, but that would
> mean reversing an earlier design decision.

Actually if you pass a parameter name to the bracketed-paste widget,
it stuffs the pasted content in there and does literally nothing else.
So a simple wrapper widget that doesn't mess with the yank buffer
could look like this:

my-bracketed-paste () {
  local wantquote=${NUMERIC:-0}
  local content
  zle .$WIDGET -N content
  if (( $wantquote == 1 )); then
    content=${(q-)content}
  fi
  LBUFFER+=$content
}

Or if you don't care about quoting the input ever, just

my-bracketed-paste () {
  local content
  zle .$WIDGET -N content
  LBUFFER+=$content
}

(see also the bracketed-paste-url-magic function distributed with zsh)

-- 
Mikael Magnusson

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Bart Schaefer]

On Oct 27, 12:12am, lolilolicon wrote:
}
} I assumed the kill ring was used for implementation convenience.
} If this was a deliberate design decision, I don't understand how this
} is desirable to the user.

It's common behavior of GUI / windowing editors, i.e., if you cut/paste
text into GNU Emacs the text is placed in the cut buffer.  (In fact in
emacs' GUI it's in the cut buffer as soon as you cut from the source,
so you can immediately yank it, but that can't happen with an app in
a text terminal.)

} This doesn't seem to be documented, so I think it's OK to change it.

Good point that it should be documented.  It's mentioned under the
YANK_* variables in "man zle" but not explicitly spelled out under the
description of the widget.

-- 
Barton E. Schaefer

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Bart Schaefer]

On Oct 27, 12:05am, Mikael Magnusson wrote:
}
} Actually if you pass a parameter name to the bracketed-paste widget,
} it stuffs the pasted content in there and does literally nothing else.

Indeed, I forgot about that.  Minimally:

    my-bracketed-paste () {
      zle .bracketed-paste 'LBUFFER[CURSOR+1]'
    }

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Daniel Shahaf]

Bart Schaefer wrote on Wed, Oct 26, 2016 at 16:51:38 -0700:
> On Oct 27, 12:12am, lolilolicon wrote:
> } This doesn't seem to be documented, so I think it's OK to change it.
> 
> Good point that it should be documented.
>

The following documents the incumbent killring behaviour, and rearranges
text to clarify that a numeric argument is ignored when a positional
argument is present.

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 726e973..3fb7f42 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -2176,10 +2176,12 @@ item(tt(bracketed-paste))(
 This widget is invoked when text is pasted to the terminal emulator. It
 is not intended to be bound to actual keys but instead to the special
 sequence generated by the terminal emulator when text is pasted.
+
+If called from a widget function and a positional argument is given,
+it is interpreted as a variable name to which the pasted text is assigned.
+Otherwise, the pasted text is inserted to the buffer and added to the kill ring.
 If a numeric argument is given, shell quoting will be applied to the
-pasted text before it is inserted. When called from a widget function,
-an argument can be given to specify a variable to which pasted text is
-assigned.
+pasted text before it is inserted.
 
 See also the tt(zle_bracketed_paste) parameter.
 )

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Daniel Shahaf]

Daniel Shahaf wrote on Thu, Oct 27, 2016 at 00:45:00 +0000:
> Bart Schaefer wrote on Wed, Oct 26, 2016 at 16:51:38 -0700:
> > On Oct 27, 12:12am, lolilolicon wrote:
> > } This doesn't seem to be documented, so I think it's OK to change it.
> > 
> > Good point that it should be documented.
> >
> 
> The following documents the incumbent killring behaviour, and rearranges
> text to clarify that a numeric argument is ignored when a positional
> argument is present.

Alternative patch after feedback by Bart.

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 726e973..e82c12d 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -2176,10 +2176,13 @@ item(tt(bracketed-paste))(
 This widget is invoked when text is pasted to the terminal emulator. It
 is not intended to be bound to actual keys but instead to the special
 sequence generated by the terminal emulator when text is pasted.
+The pasted text is inserted to the buffer and placed in the cutbuffer.
 If a numeric argument is given, shell quoting will be applied to the
-pasted text before it is inserted. When called from a widget function,
-an argument can be given to specify a variable to which pasted text is
-assigned.
+pasted text before it is inserted.
+
+When called from a widget function as `tt(bracketed-paste) var(name)`, the
+pasted text is assigned to the variable var(name) and no other processing is
+done.
 
 See also the tt(zle_bracketed_paste) parameter.
 )

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Greg Klanderman]

>>>>> On October 26, 2016 Bart Schaefer <schaefer@brasslantern.com> wrote:

> It's common behavior of GUI / windowing editors, i.e., if you cut/paste
> text into GNU Emacs the text is placed in the cut buffer.

Really???

Neither GNU emacs nor xemacs behave that way by default for me.

I have just tested GNU Emacs 24.4.1 and xemacs 24.4.22, both with
the "-q" option.

I tend to agree with the OP; this really seems like a mis-feature.

Greg

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Bart Schaefer]

On Oct 27,  3:56pm, Greg Klanderman wrote:
} Subject: Re: Shift-Insert overwrites ZLE CUTBUFFER
}
} >>>>> On October 26, 2016 Bart Schaefer <schaefer@brasslantern.com> wrote:
} 
} > It's common behavior of GUI / windowing editors, i.e., if you cut/paste
} > text into GNU Emacs the text is placed in the cut buffer.
} 
} Really???

Certainly seems to work that way for me (emacs on Ubuntu / GNOME).
*Not* when running emacs inside a terminal, however.

} I tend to agree with the OP; this really seems like a mis-feature.

I'm not particularly invested in this, because most of the time I
think bracketed-paste itself is a misfeature (or at least having it
active by default is).  However, I didn't implement the feature, so
I'm not going to un-implement it without hearing from Oliver (who
did), because obviously he had another opinion.

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Oliver Kiddle]

On 27 Oct, Bart wrote:
> Certainly seems to work that way for me (emacs on Ubuntu / GNOME).
> *Not* when running emacs inside a terminal, however.

This particular feature was added in workers/35824 along with a specific
request for actual Emacs users to check that it makes sense. In a wider
GUI sense, there is normally a single shared clipboard though copying
rather than pasting will update it.

Reverting it would be a matter of changing the cuttext call back
to doinsert. However, having the pasted text available in some form
is useful. Does anyone have an alternative suggestion?

Associating it with the existing cut/paste features at least puts
it in a logical and memorable place, at least once you're aware of
the feature. And if you know about things like yank-pop or vi "0
then it is not so likely to be bothersome. But I'd be open to
something better.

If Daniel's documentation from 22036 is applied, it should probably
also mention that in vi mode, it allows a register to be specified
to capture a paste. In that case, the text isn't inserted.

Oliver

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Peter Stephenson]

On Mon, 31 Oct 2016 16:56:54 +0100
Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> Reverting it would be a matter of changing the cuttext call back
> to doinsert. However, having the pasted text available in some form
> is useful. Does anyone have an alternative suggestion?

I'm not particularly bothered either way, but $ZLE_PASTED suggest
itself.

pws

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Daniel Shahaf]

Oliver Kiddle wrote on Mon, Oct 31, 2016 at 16:56:54 +0100:
> On 27 Oct, Bart wrote:
> If Daniel's documentation from 22036 is applied, it should probably
> also mention that in vi mode, it allows a register to be specified
> to capture a paste. In that case, the text isn't inserted.

It had already been applied.  Here's a shot at the new text; feel free
to just discard it and commit something else (that'd be easier than
doing iterations on list).

It uses the term "register" as in your email and in Vim, however, that
term occurs only once in zshzle(1).

Cheers,

Daniel

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 64bfcc2..63f673b 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -2175,9 +2175,12 @@ item(tt(bracketed-paste))(
 This widget is invoked when text is pasted to the terminal emulator. It
 is not intended to be bound to actual keys but instead to the special
 sequence generated by the terminal emulator when text is pasted.
-The pasted text is inserted to the buffer and placed in the cutbuffer.
+
+When invoked interactively, the pasted text is inserted to the buffer.
 If a numeric argument is given, shell quoting will be applied to the
 pasted text before it is inserted.
+The text is also placed in the cutbuffer, or in the specified register
+(tt("x) in vi mode).
 
 When called from a widget function as `tt(bracketed-paste) var(name)`, the
 pasted text is assigned to the variable var(name) and no other processing is

Re: Shift-Insert overwrites ZLE CUTBUFFER

[Daniel Shahaf]

Daniel Shahaf wrote on Tue, Nov 01, 2016 at 17:03:28 +0000:
> Oliver Kiddle wrote on Mon, Oct 31, 2016 at 16:56:54 +0100:
> > On 27 Oct, Bart wrote:
> > If Daniel's documentation from 22036 is applied, it should probably
> > also mention that in vi mode, it allows a register to be specified
> > to capture a paste. In that case, the text isn't inserted.
> 
> It had already been applied.  Here's a shot at the new text;

A bug was pointed out off-list after I committed the new text.  Here's
another shot for review.  The last hunk is in vi-set-buffer's docs.

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 63f673b..b7bb23b 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -2176,11 +2176,13 @@ This widget is invoked when text is pasted to the terminal emulator. It
 is not intended to be bound to actual keys but instead to the special
 sequence generated by the terminal emulator when text is pasted.
 
-When invoked interactively, the pasted text is inserted to the buffer.
+When invoked interactively, the pasted text is inserted to the buffer
+and placed in the cutbuffer.
 If a numeric argument is given, shell quoting will be applied to the
 pasted text before it is inserted.
-The text is also placed in the cutbuffer, or in the specified register
-(tt("x) in vi mode).
+
+When a named buffer is specified with tt(vi-set-buffer) (tt("x)),
+the pasted text is stored in that named buffer but not inserted.
 
 When called from a widget function as `tt(bracketed-paste) var(name)`, the
 pasted text is assigned to the variable var(name) and no other processing is
@@ -2410,7 +2412,7 @@ concerned replaces the previous contents of the specified buffer. If
 a named buffer is specified using a capital, the newly cut text is
 appended to the buffer instead of overwriting it. When using the tt("_)
 buffer, nothing happens. This can be useful for deleting text without
-affecting the normal registers.
+affecting any buffers.
 
 If no buffer is specified for a cut or change command, tt("1) is used, and
 the contents of tt("1) to tt("8) are each shifted along one buffer;