Can't paste into new windows when clipboard is set to unnamedplus

[Jason Pleau]

Hello,

I cannot paste from the system clipboard with vim if it is opened after
I copied my text into the clipboard. I am using set clipboard=unnamedplus.

A bisect with hg has lead me to believe that this change introduced my
clipboard issue:

http://code.google.com/p/vim/source/detail?r=7766142fc7d3e90c2e15a9c606efcd97331edef8



I am on Linux (Debian unstable).

This is what I use as a minimal vimrc to reproduce:

set clipboard=unnamedplus
finish

--

I was compiling vim with this command:

/configure --prefix=$HOME/vim-test/local --enable-multibyte --enable-xim
--with-features=huge && make && make install



To reproduce:

1. Copy some text into the system clipboard (with ctrl-c in chromium or
firefox for example).

2. open vim/gvim (using the .vimrc I wrote above)

3. Try to paste using p or "+p - I get E353: Nothing in register +

4. If you copy your text again and try to paste in the same vim window,
it will work.



Thanks !

[Hashken]

Add the following to .vimrc

"Copy contents of System Clipboard to + buffer when entering vim
autocmd VimEnter * call setreg('+', system('xsel -ob'))
"Copy contents of + buffer to System Clipboard while leaving vim
autocmd VimLeave * call system("xsel -ib", getreg('+'))

This should solve your problem and also the problem of vim "+" buffer contents not being availble to System Clipboard when vim is exited.

Note: Thanks to @Raimondi at #vim for helping me with the solution.

[Jason Pleau]

> "Copy contents of System Clipboard to + buffer when entering vim
>
> autocmd VimEnter * call setreg('+', system('xsel -ob'))
>
> "Copy contents of + buffer to System Clipboard while leaving vim
>
> autocmd VimLeave * call system("xsel -ib", getreg('+'))
>
>
>
> This should solve your problem and also the problem of vim "+" buffer contents not being availble to System Clipboard when vim is exited.
>
>
>
> Note: Thanks to @Raimondi at #vim for helping me with the solution.

This indeed solves the clipboard issue, but using this minimal vimrc:

set nocompatible
set clipboard=unnamedplus

autocmd VimEnter * call setreg('+', system('xsel -ob'))

autocmd VimLeave * call system("xsel -ib", getreg('+'))

And then running for example vim some_empty_file

The statusline becomes this:

"some_empty_file" [New File]^[[2;2R^[[>1;2802;0c

Notice the garbage text next to [New File]. Also, starting vim without a file can also add the same garbage text in the first line.

At this point this might belong to v...@vim.org. It's true that a patch introduced this issue, but if we can fix it with vimrc, then I don't think vim_dev is the ideal place.

Thank you!

[Christian Brabandt]

Hi Jason!

On Di, 09 Sep 2014, Jason Pleau wrote:

> Hello,
>
> I cannot paste from the system clipboard with vim if it is opened
> after I copied my text into the clipboard. I am using set
> clipboard=unnamedplus.
>
> A bisect with hg has lead me to believe that this change introduced
> my clipboard issue:
>
> http://code.google.com/p/vim/source/detail?r=7766142fc7d3e90c2e15a9c606efcd97331edef8
>
>
>
> I am on Linux (Debian unstable).
>
> This is what I use as a minimal vimrc to reproduce:
>
> set clipboard=unnamedplus
> finish

Interesting. I can reproduce the issue. I can't see how patch 7.4.396 can cause
this. However I noticed a couple of things:

vim -u <(echo set clipboard=unnamedplus) -N (paste - E353)
vim -u <(echo set clipboard=unnamedplus) -N --noplugin (paste - E353)
vim -u NONE -N -c 'set clipboard=unnamedplus' (paste works)
vim -u <(echo set clipboard=unnamedplus ei=VimEnter) -N (paste works)
vim -u <(echo ':au VimEnter * :set clipboard=unnamedplus' ) -N (paste - E353)


I am not sure how to debug this further. When running a debug built with gdb, it
always pastes correctly.

Best,
Christian
--
Macht ist das stärkste Aphrodisiakum.
-- Henry Kissinger

[Christian Brabandt]

Hi Hashken!

On Mi, 10 Sep 2014, Hashken wrote:

> On Wednesday, September 10, 2014 6:31:53 AM UTC+5:30, Jason Pleau wrote:
> Add the following to .vimrc
>
> "Copy contents of System Clipboard to + buffer when entering vim
> autocmd VimEnter * call setreg('+', system('xsel -ob'))
> "Copy contents of + buffer to System Clipboard while leaving vim
> autocmd VimLeave * call system("xsel -ib", getreg('+'))

I don't think, this should be necessary.

Best,
Christian
--
Lieber ein lohnendes Wochenende, als ein Ende des Wochenlohns.

[Jason Pleau]

Hello Christian

I have tested your two cases where the paste worked, and indeed it works, however the clipboard gets emptied when vim exits.

I'll try to pinpoint what causes this in 7.4.396 (I blindly trusted hg bisect there, and since the commit was talking about the clipboard, I assumed it was this one. I'll run another bisect just in case)

Thanks

[John Little]

On Wednesday, September 10, 2014 1:01:53 PM UTC+12, Jason Pleau wrote:
> I cannot paste from the system clipboard with vim if it is opened after
> I copied my text into the clipboard. I am using set clipboard=unnamedplus.

Are you using a clipboard manager? In KDE this is klipper, and with LXDE one can install "parcellite", if I've got that correctly.

Regards, John Little

[Jason Pleau]

Hello John. Unfortunately I am not using any clipboard manager. I am using a barebones window manager (i3 http://i3wm.org), with gnome-settings-daemon (at home), and xfce4-settingsd (at work). As far as I know, none of them has a clipboard manager.

I couldn't do a new bisect yesterday, I'll have more time to do another one tonight, and play with the code changes of 7.4.396

Thanks

[John Little]

On Saturday, September 13, 2014 12:48:01 AM UTC+12, Jason Pleau wrote:

> Hello John. Unfortunately I am not using any clipboard manager. I am using a barebones window manager (i3 http://i3wm.org), with gnome-settings-daemon (at home), and xfce4-settingsd (at work). As far as I know, none of them has a clipboard manager.

Clipit is reported to work with i3 (in the i3 FAQ), and clipman works with XFCE.

Regards, John Little

[Jason Pleau]

Le jeudi 11 septembre 2014 14:23:46 UTC-4, Christian Brabandt a écrit :

Hello again Christian

I have worked a bit on this tonight, and another bisect revealed 396 as the root of the issue.

I don't have much knowledge of vim's source code.. however please see the attached patch. Removing the start_global_changes() and end_global_changes() in src/ex_cmds2.c fixes the issue for me. (note: I haven't tested anything else except the issue at hand, with this patch)

I'm not familiar with vim internals to understand everything from start_global_changes() and end_global_changes(), they seem to save the clipboard (and "emptying" the unnamed clipboard), and then restore it. I can see mentions of CLIP_UNNAMED_PLUS in end_global_changes(), but not in start_global_changes()

Thanks !

[Christian Brabandt]

On Fr, 12 Sep 2014, Jason Pleau wrote:

> Le jeudi 11 septembre 2014 14:23:46 UTC-4, Christian Brabandt a écrit:
> > Interesting. I can reproduce the issue. I can't see how patch
> > 7.4.396 can cause this. However I noticed a couple of things:
> >
> > vim -u <(echo set clipboard=unnamedplus) -N (paste - E353)
> >
> > vim -u <(echo set clipboard=unnamedplus) -N --noplugin (paste - E353)
> >
> > vim -u NONE -N -c 'set clipboard=unnamedplus' (paste works)
> >
> > vim -u <(echo set clipboard=unnamedplus ei=VimEnter) -N (paste works)
> >
> > vim -u <(echo ':au VimEnter * :set clipboard=unnamedplus' ) -N (paste - E353)
> >
> > I am not sure how to debug this further. When running a debug built
> > with gdb, it always pastes correctly.
> >
>

> I have worked a bit on this tonight, and another bisect revealed 396
> as the root of the issue.
>
> I don't have much knowledge of vim's source code.. however please see
> the attached patch. Removing the start_global_changes() and
> end_global_changes() in src/ex_cmds2.c fixes the issue for me. (note:
> I haven't tested anything else except the issue at hand, with this
> patch)

Your patch basically just disables, what Patch 7.4.396 did. The purpose
of this patch was to disable accessing the system clipboard only on very
specific occasions, e.g. when using :bufdo, :g, :folddo etc. So that Vim
does seem to hang, by accessing the system clipboard many times in short
terms (which it seem to do on Windows). This has nothing to do with
startup and I don't see, how this can affect startup.

Plus, this seems to be highly dependent on the system as accessing the
clipboard works, when running under gdb. I am at loss, how that can have
an impact here. Perhaps Bram has an idea.

Best,
Christian

--
Denn das Wort ist wahr, daß ein Extrem regelmässig das
entgegengesetzte Extrem auslöst. Das gilt so beim Wetter, in unseren
Körpern und erst recht bei den Staaten.
-- Sokrates (470-399 v.Chr.)

[Jason Pleau]

I have digged a bit deeper, and it seems that in ex_cmds2.c, ex_listdo() is called when I launch vim (the command is: windo call s:LocalBrowse(expand("%:p")). So start_global_changes() is effectively launched when opening vim.

ex_listdo is called for :argdo, :windo, :bufdo and :tabdo. Do *_global_changes() need to be called for these other than :bufdo?

[Bram Moolenaar]

Not really. Perhaps end_global_changes() clears the clipboard in a
specific sequence of events? There might be a race condition, causing
it to work when running in gdb. Or with/without using the optimizer?

--
hundred-and-one symptoms of being an internet addict:
126. You brag to all of your friends about your date Saturday night...but
you don't tell them it was only in a chat room.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Jason Pleau]

Hello again.

Thanks to Pauli from https://code.google.com/p/vim/issues/detail?id=257 , the :windo call is from the netrwPlugin.vim plugin.

So at least we know where the start_global_changes() call at vim startup comes from. My previous post still stands, do we want start_global_changes() to fire at :windo ? In the meantime I'll disable the plugin as it fixes the issue for me

[Christian Brabandt]

On Sa, 13 Sep 2014, Bram Moolenaar wrote:

> Not really. Perhaps end_global_changes() clears the clipboard in a
> specific sequence of events? There might be a race condition, causing
> it to work when running in gdb. Or with/without using the optimizer?

Oh why, didn't I see this? I feel so stupid. Yes that is basically what
happens. end_global_changes() calls clip_gen_set_selection() which
clears the clipboard, which it shouldn't when starting up.

I couldn't reproduce it, because I usually run vim from it's built
directory, and in this case the netrw plugin wasn't executed...

diff --git a/src/main.c b/src/main.c
--- a/src/main.c
+++ b/src/main.c
@@ -958,8 +958,16 @@ vim_main2(int argc UNUSED, char **argv U
if (p_im)
need_start_insertmode = TRUE;

+#ifdef FEAT_CLIPBOARD
+ if (clip_unnamed)
+ clip_did_set_selection = -1; /* do not overwrite system clipboard, when starting up */
+#endif
#ifdef FEAT_AUTOCMD
apply_autocmds(EVENT_VIMENTER, NULL, NULL, FALSE, curbuf);
+#ifdef FEAT_CLIPBOARD
+ if (clip_did_set_selection < 0)
+ clip_did_set_selection = TRUE;
+#endif
TIME_MSG("VimEnter autocommands");
#endif

diff --git a/src/ui.c b/src/ui.c
--- a/src/ui.c
+++ b/src/ui.c
@@ -571,7 +571,7 @@ start_global_changes()
{
clip_unnamed_saved = clip_unnamed;

- if (clip_did_set_selection)
+ if (clip_did_set_selection > 0)
{
clip_unnamed = FALSE;
clip_did_set_selection = FALSE;
@@ -584,7 +584,7 @@ start_global_changes()
void
end_global_changes()
{
- if (!clip_did_set_selection)
+ if (clip_did_set_selection == 0)
{
clip_did_set_selection = TRUE;
clip_unnamed = clip_unnamed_saved;


Best,
Christian
--
Was man mündlich ausspricht, muss der Gegenwart, dem Augenblick
gewidmet sein; was man schreibt, widme man der Ferne, der Folge.
-- Goethe, Maximen und Reflektionen, Nr. 585

[Jason Pleau]

Works for me!
Tested against 7.4.443

Thanks a lot Christian!

Jason