Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Detailed steps to reproduce the behavior:
Expected behavior
expect the content pasted ok/there.
Screenshots
n/a.
Environment (please complete the following information):
Vi IMproved 8.1 (2018 May 18, compiled Sep 22 2019 21:50:45)
Included patches: 1-2065
Additional context
should be some runtime plugin caused this - i guessed.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Closed #4965.
that is not how the clipboard works on linux. In short, install a clipboard manager. Duplicate of #4841 and see the provided other information.
that's not a duplicated case as #4841,
i copied the text from outside (not in vim), but vim somehow made it lost !
Reopened #4965.
but i agree those both can be workaround by a clipboard mgr.
just if i did not recall wrong, (for this case) it worked in the past ..
beside, vim should not impact the system clipboard if just in&out of vim (did not opt anything else).
Please use correct wording and exact, reproducible steps, otherwise we don't know what you are doing.
On Ubuntu there is the selection and the clipboard, Vim supports both.
Instead of "try to paste it" say what command you used exactly.
1, open a page in 'firefox' - left mouse select some text - right mouse copy them into clipboard.
2, 'mv .vim abc'
3, 'vim --clean' open and 'i' and 'ctrl+shift+v'.
4, ':q!' quit vim and 'ctrl+shift+v' at cli -> paste ok.
5, 'vim' open vim and 'i' and 'ctrl+shift+v'.
6, ':q!' quit vim and 'ctrl+shift+v' at cli -> nothing to paste.
the detail reproduce as above.
and the 'ctrl+shift+v' in the step 3 and 5 was not necessary (not a must) which can reproduce it still without them.
'nothing to paste' means none output when you issued 'ctrl+shift+v'.
In Vim, Ctrl-Shift-V is exactly the same as Ctrl-V and in Insert mode, both are suppose to "literalize" your next keypress (see :help i_CTRL-V and :help i_CTRL-V_digit).
There are two possible exceptions:
So I have two questions for you:
<MiddleMouse>.)Best regards,
Tony.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.![]()
1, xfce-term
2, same problem if gvim (though 'ctrl+shift+v' looks not work same like in 'vim')
as long as enter into vim or gvim, then quit from it,
the content in the clipboard which copied before (before enter into vim/gvim) can not paste by 'ctrl+shift+v' (after 'quit' vim/gvim).
same problem if xterm.
Have you tried other ways of pasting?
same problem if just left mouse copy and right mouse paste (without hotkey).
to me, i guess some vim runtime plugin took over clipboard, then "clean" it after 'quit' vim.
that's the why, looks ...
but if i did not do a 'yank' in the 'vim', then 'vim' should not do such "clean".
so i think that's a 'bug'.
Have you installed any vim plugins to the system vimfiles directory? Check /usr/share/vim/vimfiles. Also check /etc/vimrc and ~/.vimrc.
In this step
5, 'vim' open vim and 'i' and 'ctrl+shift+v'.
What if you quit Vim as soon as it opens?
What if you run echo sth | xsel -nib and in a new terminal do the step 5? Does the previous xsel command exit? If not, does it exit after you quit Vim?
step 2 <-- user/third-part plugins had been cleaned for the test.
same problem if just left mouse copy and right mouse paste (without hotkey).
That is a different clipboard (primary). How about :put +, how about i_CTRL-R-+?
Does it depend on your desktop environment? What is the complete :version output? Also please answer the question from @lilydjwg
And what about (if you do not paste), simply use :echo getreg('+')? Does is also happen if you do not access the clipboard at all?
i found the cause:
in the &runtimepath/autoload/netrw.vim
at the begin of some explore func:
if has("clipboard")
sil! let @* = keepregstar
sil! let @+ = keepregplus
endif
then at some place of it:
if has("clipboard")
sil! let @* = keepregstar
sil! let @+ = keepregplus
endif
but it probably was 'empty', then that's the why the clipboard "clean" happened. looks so.
Well, the code you've found will own the clipboard and has its content lost when Vim quits. But it doesn't show why it was called. That code shouldn't have been executed if you did exactly what you've described above and have really prevented all third-party and your own config from loading.
step 2 <-- user/third-part plugins had been cleaned for the test.
Not entirely. See my last comment above.
the problem is the clipboard was not "empty", but netrw made it "empty".
workaround is: do not use 'netrw' or use a 'clipboard-mgr' helping it.
solution is: netrw author probably should review the code made the content (if it was not 'empty') do not lost.
so why was the autoloaded file loaded at all? That is probably still a bug of netrw, CC @cecamp
It seems to be a bug of netrw. Why does netrw do this? I do not see how :Explore needs to operate the clipboards and besides the ownership issue it probably will mess them up when:
somehow "keepregstar" and/or "keepregplus" was not containing the "content" which user copied out of vim before entering vim.
to me, looks that's the cause.
BTW: what netrw version are you using?
" Version: 165
netrw
So perhaps there is a bug with Vim too: Vim probably shouldn't try to read an image from clipboard as text and put it into @+.
PS my netrw is version 165 and Vim is 8.1.2027.
not a problem at window/cygwin, but linux/ubuntu, there is a little different between those 2 platform.
to linux, probably netrw should leave @+ alone, looks vim itself at linux was working like that anyway.
` if has("clipboard")
sil! let @* = keepregstar
sil! let @+ = keepregstar
sil! let @+ = keepregplus
endif
`
it was working like that last version. looks so. though a little looking confusion.
ok, that's it - all for now. leaving it for author to judge if needing to modify or not.
sil! let @+ = keepregstar
That line is not in the official runtime file autoload/netrw.vim (which is v165). Where is that from?
sil! let @+ = keepregstarThat line is not in the official runtime file autoload/netrw.vim (which is v165). Where is that from?
last version.
Well, https://github.com/vim/vim/blob/master/runtime/autoload/netrw.vim does not contain the line
sil! let @+ = keepregstar
last version: 156
so can you please verify with the latest version?
you did not get me, i mean/said "to linux, probably netrw should leave @+ alone"
the lastest version (165) use them both.
just a guess that maybe make it work. so leaving author to judge if it's ok or not.
I did completely get your point. However you did not get the point to check if the problem you stated in the very first start of this issue, is actually present with the current version. Your patch does not work since the changed line is not in the version in this repository currently so I want to know whether the bug as described by you in the beginning happens also with the current master branch.
latest version 165 is the current master branch of netrw.
last version of netrw is 156. the diff i showed is in the version 156.
the author looks was using @* only - even @+ was getting from @* too.
now i mean/said probably should leave @+ alone - Not touch. but just a guess/advice.
wish you got me now. that's all. leaving for author to judge ...
totally understood. I was just trying to understand where your diff comes into play. Also, I am still wondering why autoload/netrw.vim is actually loaded. That should only happen if you use netrw. But from your issue description this should not happen. So did you use netrw in between?
yes, i removed the '.vim', but did not remove the '.vimrc'. so that's not sth special .. :)
i was not aware of the cause came from, just knew it should be runtime somewhere.
thanks for all your joining here, it should be good for the future search/reader jump in here anyway. :)
Netrw's code is doing a save&restore with @* and @+. Without it something (not explicit) modifies those registers. Perhaps a save is missing...
wow.. thanks your @cecamp joining.
wish this could be fixed soon later, since looks that should be a very bad user-experience/concern of using netrw. waiting ... :)
This problem actually seems to be a vim problem.
- Get some text into the clipboard
- Start up vim -u NONE -U NONE
- Then :echo @* (shows the saved text)
- :let @*= "junk"
- :q!
- check clipboard (for linux, echo )
Neither the originally saved text nor the "junk" text is now in the clipboard.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.![]()
I am not sure how you tested it, but this might be expected. As Vim has quit (and therefore the xclient responsible for getting the primary selection to the X Server), the selection is usually lost.
This problem actually seems to be a vim problem.
1. Get some text into the clipboard 2. Start up vim -u NONE -U NONE 3. Then :echo @* (shows the saved text) 4. :let @*= "junk" 5. :q! 6. check clipboard (for linux, echo )Neither the originally saved text nor the "junk" text is now in the clipboard.
@cecamp probably it is a wrong case, '@*' should would not change the clipboard outside (of vim).
you probably used '@+', i guess/think your code should not copy text into '@+'.
as for the lost of '@+' as @chrisbra said, i do not know the tech detail, but to most Vimer, i think we did not like to lost it (too - though different case like here), and looks it did not happen if at windows/cygwin.
The problem is that yanks modify the clipboard. I was using a save and restore to cover this issue, but it appears that when vim exits then the "restored" clipboard value is promptly lost. If there's a way to prevent yanks from modifying the clipboard I could use that.
what's version of vim you are using? at my vim8.1.2159 i can not re-produce your 'lost' if using '@*'.
as your code in v165, you are using both of them. i am not sure your purpose of save/restore fully, or perhaps it is a old version of vim which was a history issue ? :)
as for the lost of '@+' as @chrisbra said, i do not know the tech detail, but to most Vimer, i think we did not like to lost it (too - though different case like here), and looks it did not happen if at windows/cygwin.
Maybe the problem is that on Windows the "* and "+ are the same?
…
-- hundred-and-one symptoms of being an internet addict: 24. You realize there is not a sound in the house and you have no idea where your children are. /// 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 ///
obviously there is no x-server/client issue at windows/cygwin.
I felt strangely (at Linux) if did not touch @+ during in vim, then when exit vim, it will not lost, otherwise it happened.
thanks,
The problem is that yanks modify the clipboard. I was using a save and restore to cover this issue, but it appears that when vim exits then the "restored" clipboard value is promptly lost. If there's a way to prevent yanks from modifying the clipboard I could use that.
It should not be needed to save and restore the clipboard. Perhaps the 'clipboard' option is set or "a" appears in 'guioptions'? Temporarily removing those would work better.
…
-- Me? A skeptic? I trust you have proof. /// 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 ///
looks yes, if set 'autoselect' in that option, would change value of @* if yank.
@cecamp
Netrw's code is doing a save&restore with @* and @+. Without it something (not explicit) modifies those registers. Perhaps a save is missing...
The problem is that yanks modify the clipboard. I was using a save and restore to cover this issue, but it appears that when vim exits then the "restored" clipboard value is promptly lost. If there's a way to prevent yanks from modifying the clipboard I could use that.
What code specifically would modify those registers? In netrw's code, I see places where either a register is explicitly overriden (although * and + is never overriden), or where the default register is overriden. If the save&restore is done to protect against the default register being * or + which would in turn cause the system clipboard to be modified, then a simple fix would be to use the _ register (or be explicit when doing a yank/delete) and the save&restore code can be removed.
There's no mystery about why Vim is faster, this is a known issue. Nvim invokes shell commands to work with the clipboard, whereas Vim uses the OS API.
um, ok then, good to know. i have no chance to feel nvim yet, but if so, looks it solved the clipboard lost issue, but just slow. :)
looks it solved the clipboard lost issue
Using the shell commands to work with the clipboard wouldn't necessarily solve the issue you were having.
not sue - it said nvim using pbcopy and pbpaste - if to com with system clipboard, looks system clipboard content would be kept even it exit, but i have not tried nvim, just guess so.
anyway, whatever that issue or this netrw issue, it's not about me, sooner or later Vimer would face that or facing now - would be surprised where is my clipboard content .. :)
Please try this patch:
--- ../../git/vim81/runtime/autoload/netrw.vim 2019-11-10 22:06:05.354101842 +0100
+++ autoload/netrw.vim 2019-11-22 21:57:30.615741611 +0100
@@ -918,8 +918,8 @@
NetrwKeepj call netrw#ErrorMsg(s:WARNING,"using Nexplore or improperly; see help for netrw-starstar",40)
if has("clipboard")
" call Decho("(netrw#Explore) restore @* and @+",'~'.expand(""))
sil! let @* = keepregstar
sil! let @+ = keepregplus
if @* != keepregstar | sil! let @* = keepregstar | endif
if @+ != keepregplus | sil! let @+ = keepregplus | endif
endif
sil! let @/ = keepregslash
" call Dret("netrw#Explore")
@@ -944,8 +944,8 @@
NetrwKeepj call netrw#ErrorMsg(s:WARNING,"using Pexplore or improperly; see help for netrw-starstar",41)
if has("clipboard")
" call Decho("(netrw#Explore) restore @* and @+",'~'.expand(""))
sil! let @* = keepregstar
sil! let @+ = keepregplus
if @* != keepregstar | sil! let @* = keepregstar | endif
if @+ != keepregplus | sil! let @+ = keepregplus | endif
endif
sil! let @/ = keepregslash
" call Dret("netrw#Explore")
@@ -1000,8 +1000,8 @@
if &hls | let keepregslash= s:ExplorePatHls(pattern) | endif
if has("clipboard")
" call Decho("(netrw#Explore) restore @* and @+",'~'.expand(""))
if @* != keepregstar | sil! let @* = keepregstar | endif
if @+ != keepregplus | sil! let @+ = keepregplus | endif
endif
sil! let @/ = keepregslash
" call Dret("netrw#Explore : no files matched pattern")
@@ -1037,8 +1037,8 @@
keepalt NetrwKeepj call netrw#ErrorMsg(s:WARNING,"no files matched",42)
if has("clipboard")
" call Decho("(netrw#Explore) restore @* and @+",'~'.expand(""))
sil! let @* = keepregstar
sil! let @+ = keepregplus
if @* != keepregstar | sil! let @* = keepregstar | endif
if @+ != keepregplus | sil! let @+ = keepregplus | endif
endif
sil! let @/ = keepregslash
" call Dret("netrw#Explore : no files matched")
@@ -1086,8 +1086,8 @@
endif
if has("clipboard")
" call Decho("(netrw#Explore) restore @* and @+",'~'.expand(""))
sil! let @* = keepregstar
sil! let @+ = keepregplus
if @* != keepregstar | sil! let @* = keepregstar | endif
if @+ != keepregplus | sil! let @+ = keepregplus | endif
endifyes, i tried, IF just to this netrw issue itself in this ticket and the test case i raised here, looks this is a way and workaround. thanks. @brammool
closing, this issue (per my case) should had been fixed. thx.
Closed #4965.