[vim/vim] lost content of system clipboard after in/out vim (#4965)

[Shane-XB-Qian]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Detailed steps to reproduce the behavior:

1. copy text in the notepad or somewhere.
2. mv .vim abc
3. 'vim --clean' and 'i' and try to paste it.
4. ':q!' the vim - try to paste it at bash/cli -> paste ok.
5. 'vim' and 'i' and try to paste it.
6. ':q!' the vim - try to paste it at bash/cli -> nothing to paste.

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

• Ubuntu 18.04

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

[Christian Brabandt]

Closed #4965.

[Christian Brabandt]

that is not how the clipboard works on linux. In short, install a clipboard manager. Duplicate of #4841 and see the provided other information.

[Shane-XB-Qian]

that's not a duplicated case as #4841,
i copied the text from outside (not in vim), but vim somehow made it lost !

[Christian Brabandt]

Reopened #4965.

[Shane-XB-Qian]

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).

[Bram Moolenaar]

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.

[Shane-XB-Qian]

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.

[Shane-XB-Qian]

'nothing to paste' means none output when you issued 'ctrl+shift+v'.

[Tony Mechelynck]

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:

• if you run Vim (not gvim) in a console and that console snatches the Ctrl-(Shift-)V keypress before Vim sees it
• if insert-mode Ctrl-V is remapped to something else, which can happen if, for instance, the mswin.vim script has been sourced.

So I have two questions for you:

• In which console emulator did run Vim? (xterm, konsole, gnome-terminal, other, and in the latter case, which other?)
• Do you get he same problem when using gvim rather than Vim-in-console? (To paste the clipboard in gvim, use Edit→Paste; to paste the selection, use <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.

[Shane-XB-Qian]

1, xfce-term
2, same problem if gvim (though 'ctrl+shift+v' looks not work same like in 'vim')

[Shane-XB-Qian]

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).

[Shane-XB-Qian]

same problem if xterm.

[Christian Brabandt]

Have you tried other ways of pasting?

[Shane-XB-Qian]

same problem if just left mouse copy and right mouse paste (without hotkey).

[Shane-XB-Qian]

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?

[Shane-XB-Qian]

step 2 <-- user/third-part plugins had been cleaned for the test.

[Christian Brabandt]

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

[Christian Brabandt]

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?

[Shane-XB-Qian]

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.

[Shane-XB-Qian]

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.

[Christian Brabandt]

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:

• the clipboard content is not text
• Vim is connecting to X via a slow ssh and there are a handful of data on clipboard (that isn't supported to be transmitted to Vim)

[Shane-XB-Qian]

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.

[Christian Brabandt]

BTW: what netrw version are you using?

[Shane-XB-Qian]

" 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.

[Shane-XB-Qian]

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.

[Shane-XB-Qian]

` 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.

[Shane-XB-Qian]

ok, that's it - all for now. leaving it for author to judge if needing to modify or not.

[Christian Brabandt]

•   sil! let @+ = keepregstar
  

That line is not in the official runtime file autoload/netrw.vim (which is v165). Where is that from?

[Shane-XB-Qian]

•   sil! let @+ = keepregstar
  

That line is not in the official runtime file autoload/netrw.vim (which is v165). Where is that from?

last version.

[Christian Brabandt]

Well, https://github.com/vim/vim/blob/master/runtime/autoload/netrw.vim does not contain the line

sil! let @+ = keepregstar

[Shane-XB-Qian]

last version: 156

[Christian Brabandt]

so can you please verify with the latest version?

[Shane-XB-Qian]

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.

[Christian Brabandt]

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.

[Shane-XB-Qian]

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 ...

[Christian Brabandt]

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?

[Shane-XB-Qian]

yes, i removed the '.vim', but did not remove the '.vimrc'. so that's not sth special .. :)

[Shane-XB-Qian]

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. :)

[cecamp]

Netrw's code is doing a save&restore with @* and @+. Without it something (not explicit) modifies those registers. Perhaps a save is missing...

[Bram Moolenaar]

Charles wrote:

> Netrw's code is doing a save&restore with @* and @+. Without it
> something (not explicit) modifies those registers. Perhaps a save is
> missing...

Since it's possible the restore drops information (e.g., whether the
operation was blockwise), perhaps it should only happen when the
registers are actually changed? Thus:

{save registers}

- do stuff

if {changing @* or @+}
let need_restore = 1
endif

- do stuff

if need_restore
{restore registers}
endif

--
A vacation is a period of travel during which you find that you
took twice as many clothes and half as much money as you needed.

/// 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 ///

[Shane-XB-Qian]

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 ... :)

[cecamp]

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.

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub, or unsubscribe.

[Christian Brabandt]

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.

[Shane-XB-Qian]

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 '@+'.

[Shane-XB-Qian]

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.

[cecamp]

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.

[Shane-XB-Qian]

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 ? :)

[Chr. von Stuckrad]

Hi! to all the answering people on X11-Displays.

Having some of those 'losts' too I want to throw in, that
very often a 'clipboard manager' is running in background
and is complicating the debugging (even bringing the tests
of vim to fail). Those managers grab incoming changes from
@* _AND_ @+, and put, if enabled, the latest change into
both, then keep on to service the contents 'forever' (as
long as the service is running). The exact working of the
different managers of different 'desktop's (like 'gnome',
'kde', or 'xfce') or of other independent ones like 'diodon'
may behave slightly different, but always keeping @+ along.

So to be sure, to see what 'vim' does itself, make
absolutely sure _NOT_ to run such a beast, while
compiling/debugging vim! Lest you get 'flaky' results
depending on desktop situation. On 'plain X11' clipboard
'@+' is always lost, when the program, which created/keeps
the contents is going away.

Stucki

--
Christoph von Stuckrad * * | also XMPP = |Mail <stu...@mi.fu-berlin.de> \
Freie Universitaet Berlin |/_*| 'jabber' via|Tel(Di.,Fr.):+49 30 77 39 6600|
IT Mathematik & Informatik|\ *|stucki@jabber| (Mo,Mi,Do):+49 30 838-75 459|
Takustr. 9 / 14195 Berlin * * |.fu-berlin.de|Fax(@home): +49 30 77 39 6601/

[Bram Moolenaar]

> 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 ///

[Bram Moolenaar]

> 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.

[Shane-XB-Qian]

obviously&nbsp;there&nbsp;is&nbsp;no&nbsp;x-server/client&nbsp;issue&nbsp;at&nbsp;windows/cygwin.
I&nbsp;felt&nbsp;strangely&nbsp;(at&nbsp;Linux)&nbsp;if&nbsp;did&nbsp;not&nbsp;touch&nbsp;@+&nbsp;during&nbsp;in&nbsp;vim,&nbsp;then&nbsp;when&nbsp;exit&nbsp;vim,&nbsp;it&nbsp;will&nbsp;not&nbsp;lost,&nbsp;otherwise&nbsp;it&nbsp;happened.&nbsp;
thanks,
-&nbsp;shane.xb.qian



---Original---
From: &quot;Bram Moolenaar&quot;<notifi...@github.com&gt;
Date: Fri, Nov 1, 2019 11:17 AM
To: &quot;vim/vim&quot;<v...@noreply.github.com&gt;;
Cc: &quot;Shane-XB-Qian&quot;<shane...@foxmail.com&gt;;&quot;Author&quot;<aut...@noreply.github.com&gt;;
Subject: Re: [vim/vim] lost content of system clipboard after in/out vim (#4965)



&gt; as for the lost of &#39;@+&#39; as @chrisbra said, i do not know the tech
&gt; detail, but to most Vimer, i think we did not like to lost it (too -
&gt; though different case like here), and looks it did not happen if at
&gt; windows/cygwin.

Maybe the problem is that on Windows the &quot;* and &quot;+ 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 ///

&mdash;
You are receiving this because you authored the thread.

[Shane-XB-Qian]

looks&nbsp;yes,&nbsp;if&nbsp;set&nbsp;'autoselect'&nbsp;in&nbsp;that&nbsp;option,&nbsp;would&nbsp;change&nbsp;value&nbsp;of&nbsp;@*&nbsp;if&nbsp;yank.&nbsp;

thanks,
-&nbsp;shane.xb.qian



---Original---
From: &quot;Bram Moolenaar&quot;<notifi...@github.com&gt;

Date: Fri, Nov 1, 2019 00:47 AM

To: &quot;vim/vim&quot;<v...@noreply.github.com&gt;;
Cc: &quot;Shane-XB-Qian&quot;<shane...@foxmail.com&gt;;&quot;Author&quot;<aut...@noreply.github.com&gt;;
Subject: Re: [vim/vim] lost content of system clipboard after in/out vim (#4965)

&gt; The problem is that yanks modify the clipboard. I was using a save
&gt; and restore to cover this issue, but it appears that when vim exits
&gt; then the &quot;restored&quot; clipboard value is promptly lost. If there&#39;s a
&gt; 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

&#39;clipboard&#39; option is set or &quot;a&quot; appears in &#39;guioptions&#39;? Temporarily

removing those would work better.

--
Me? A skeptic? I trust you have proof.

[Shane-XB-Qian]

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,

• shane.xb.qian

[Shane-XB-Qian]

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

[Adam P. Regasz-Rethy]

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.

[Shane-XB-Qian]

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. :)

[Adam P. Regasz-Rethy]

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.

[Shane-XB-Qian]

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 .. :)

[Bram Moolenaar]

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(""))

• 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 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
  

  endif
  sil! let @/ = keepregslash
  " call Dret("netrw#Explore : missing +path_extra")
  @@ -1160,8 +1160,8 @@
  let s:netrw_events= 2
  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 : @/<".@/.">")
  @@ -9602,8 +9602,8 @@
  endwhile
  if has("clipboard")
  " call Decho("(s:NetrwWideListing) restore @* and @+",'~'.expand(""))

• sil! let @*= keepregstar
• sil! let @+= keepregplus

• if @* != keepregstar | sil! let @* = keepregstar | endif
• if @+ != keepregplus | sil! let @+ = keepregplus | endif
  endif
  exe "sil! NetrwKeepj ".w:netrw_bannercnt.',$s/\s+$//e'
  NetrwKeepj call histdel("/",-1)

[Shane-XB-Qian]

yes, 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

[Shane-XB-Qian]

closing, this issue (per my case) should had been fixed. thx.

[Shane-XB-Qian]

Closed #4965.