[vim/vim] netrw is slow over ssh (#7259)
Björn Steinbrink
When using vim over SSH with X11 forwarding (might require +clipboard), netrw is really sluggish, taking up to multiple seconds when opening a directory listing.
To Reproduce
- SSH to a remote machine with X11 forwarding
- open vim compiled
- use
:e .to open the directory listing in netrw - optionally change into another directory
steps 3 and 4 should be quite sluggish
Expected behavior
I expect netrw to be as quick as without X11 forwarding. If I unset DISPLAY before starting vim, netrw is fast.
Workaround
If I execute let @* = @* and let @+ = @+ before opening netrw, netrw is fast. But I have to do this manually. Adding the commands to my vimrc does not fix the problem.
Environment:
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Oct 27 2020 11:26:41)
Included patches: 1-1911
Compiled by bs@bs2
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl -farsi +mouse_sgr +tag_binary
+arabic +file_in_path -mouse_sysmouse -tag_old_static
+autocmd +find_in_path +mouse_urxvt -tag_any_white
+autochdir +float +mouse_xterm -tcl
-autoservername +folding +multi_byte +termguicolors
+balloon_eval -footer +multi_lang +terminal
+balloon_eval_term +fork() -mzscheme +terminfo
+browse +gettext +netbeans_intg +termresponse
++builtin_terms -hangul_input +num64 +textobjects
+byte_offset +iconv +packages +textprop
+channel +insert_expand +path_extra +timers
+cindent +ipv6 -perl +title
+clientserver +job +persistent_undo +toolbar
+clipboard +jumplist +popupwin +user_commands
+cmdline_compl +keymap +postscript +vartabs
+cmdline_hist +lambda +printer +vertsplit
+cmdline_info +langmap +profile +virtualedit
+comments +libcall -python +visual
+conceal +linebreak +python3/dyn +visualextra
+cryptv +lispindent +quickfix +viminfo
+cscope +listcmds +reltime +vreplace
+cursorbind +localmap +rightleft +wildignore
+cursorshape +lua -ruby +wildmenu
+dialog_con_gui +menu +scrollbind +windows
+diff +mksession +signs +writebackup
+digraphs +modify_fname +smartindent +X11
+dnd +mouse +sound -xfontset
-ebcdic +mouseshape +spell +xim
+emacs_tags +mouse_dec +startuptime +xpm
+eval +mouse_gpm +statusline +xsmp_interact
+ex_extra -mouse_jsbterm -sun_workshop +xterm_clipboard
+extra_search +mouse_netterm +syntax -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/home/bs/vim/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -O2 -fno-strength-reduce -Wall -D_REENTRANT -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lselinux -lcanberra -lacl -lattr -lgpm -ldl -L/usr/lib -llua5.2
- OS: Debian Sid
- Terminal: alaxcritty, termite, xterm
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
E. Farrell
Yes I'm finding this too with netrw. Only happening with ssh X11 forwarding and $DISPLAY set. Doesn't happen otherwise.
Vim 8.2 (patches 1 - 1632).
Ubuntu 18.04. Gnome Terminal.
Apparently 'netrw' does something to the system clipboard. I saw the same issue came up on neovim:
[https://github.com/neovim/neovim/issues/6048](Very slow netrw operations....)
[https://github.com/neovim/neovim/issues/11089](netrw signficantly slower...)
cecamp
For ssh, netrw just acts as glue; ie. it sets up a command for ssh and has the system execute it. As far as the clipboard goes: it copies the clipboard into a local variable, and only if the clipboard value has changed during the course of netrw's operation will netrw restore the clipboard value (thus avoiding having netrw always be the last one to modify the clipboard).
Björn Steinbrink
@cecamp this is not about using netrw to browse remote files via ssh, but about using ssh to log into a remote system and using vim there to browse the "local" files on that system.
E. Farrell
Update:
I copied this fix to $VIMRUNTIME/autoload/netrw.vim for the moment.
Netrw over ssh X11 fast now...
Fix Details:
Neovim: netrw.vim: do not save +/* registers
cecamp
@dotdash -- thanks for that. In that case, check on the g:netrw_fastbrowse setting; perhaps setting it to 2 will help.
Christian Brabandt
As far as the clipboard goes: it copies the clipboard into a local variable, and only if the clipboard value has changed during the course of netrw's operation will netrw restore the clipboard value (thus avoiding having netrw always be the last one to modify the clipboard).
How about adding a configuration option to leave the clipboard alone if set. This would solve two problems:
- the clipboard won't be accessed at all if configured. That means, Neovim guys wouldn't have any problems, since the external clipboard provider may be slow.
- It won't corrupt the clipboard in case of any non-text items in it.
People complaining could then set this variable and be fine.
Charles Campbell
>
> As far as the clipboard goes: it copies the clipboard into a local
> variable, and only if the clipboard value has changed during the
> course of netrw's operation will netrw restore the clipboard value
> (thus avoiding having netrw always be the last one to modify the
> clipboard).
>
> How about adding a configuration option to leave the clipboard alone
> if set. This would solve two problems:
>
> clipboard provider may be slow.
> People complaining could then set this variable and be fine.
>
>
clipboard. That ends up with it being unexpectedly changed, which means
"clipboard won't be accessed at all" is not going to happen. Its like
history -- I don't want to change the history, but there's a lot of
operations that netrw does which change the history -- so there's a lot
of code to keep the history unchanged. I could have netrw optionally not
restore the clipboard, but I'm sure (because of earlier complaints) that
there will be a raft of new complaints. Well, I guess I'll put in
yet-another-option to prevent netrw from doing a save&restore of the
clipboard (g:netrw_clipboard).
It'd be a help if vim itself had an option to leave something alone (ie.
setl leavealone="history:clipboard:jumps"); then netrw and other plugins
could set that, do their job, then unset it.
Regards,
Chip Campbell
Christian Brabandt
On Fr, 18 Dez 2020, Charles Campbell wrote:
> Christian Brabandt (Vim Github Repository) wrote:
> >
> > As far as the clipboard goes: it copies the clipboard into a local
> > variable, and only if the clipboard value has changed during the
> > course of netrw's operation will netrw restore the clipboard value
> > (thus avoiding having netrw always be the last one to modify the
> > clipboard).
> >
> > How about adding a configuration option to leave the clipboard alone if
> > set. This would solve two problems:
> >
> > * the clipboard won't be accessed at all if configured. That means,
> > Neovim guys wouldn't have any problems, since the external
> > clipboard provider may be slow.
> > * It won't corrupt the clipboard in case of any non-text items in it.
> >
> > People complaining could then set this variable and be fine.
> >
> >
> The only problem -- something netrw does inadvertently modifies the
> clipboard. That ends up with it being unexpectedly changed, which means
> "clipboard won't be accessed at all" is not going to happen. Its like
> history -- I don't want to change the history, but there's a lot of
> operations that netrw does which change the history -- so there's a lot of
> code to keep the history unchanged. I could have netrw optionally not
> restore the clipboard, but I'm sure (because of earlier complaints) that
> there will be a raft of new complaints. Well, I guess I'll put in
> yet-another-option to prevent netrw from doing a save&restore of the
> clipboard (g:netrw_clipboard).
unintentionally. Wouldn't that only be the case when the clipboard
option is set or the guioption includes a/A/p?
I suppose if the user explicitly uses "+y to paste to the clipboard in
netrw, that should be okay.
> It'd be a help if vim itself had an option to leave something alone (ie.
> setl leavealone="history:clipboard:jumps"); then netrw and other plugins
> could set that, do their job, then unset it.
clipboard interaction be good enough?
Thanks,
Christian
--
Brüllt ein Mann, ist er dynamisch.
Brüllt eine Frau, ist sie hysterisch.
-- Hildegard Knef
Charles Campbell
issue. As I recall, the problem occurrs with wide listings, because
netrw does use visual selection to construct the columns internally.
However, I wouldn't be certain that there's nothing else involved. I
suppose that I could have netrw save&restore guioption and safe-option a
and A out.
(safe-option: what netrw uses while its constructing its display).
>
> I suppose if the user explicitly uses "+y to paste to the clipboard in
> netrw, that should be okay.
>
>> It'd be a help if vim itself had an option to leave something alone (ie.
>> setl leavealone="history:clipboard:jumps"); then netrw and other plugins
>> could set that, do their job, then unset it.
> Wouldn't setting guioptions and clipboard option to a value that exclude
> clipboard interaction be good enough?
>
all sure that it does that wherever needed even so, just to leave the
jump table alone. I'll install the save&restore&safe guioption and see
if that helps.
Regards,
Chip Campbell
Björn Steinbrink
@cecamp No, that doesn't help at all, unfortunately.
Jaehwang Jerry Jung
An option to disable restoration of the clipboard was added in the latest runtime file update.
89a9c15#diff-49e1f1e8a3b17eb217ce251d8200c88a2c9dede55a4373df3d2176a8403f7f28R2622
let g:netrw_clipboard = 0
But it seems that netrw can in fact modify the clipboard content: https://groups.google.com/g/vim_dev/c/P1lSMJNbTe0/m/7TIrLXnWAQAJ
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
Christian Brabandt
so let's close it then.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Christian Brabandt
Closed #7259.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.