1

While ssh'd into my server, vim hangs for a variable amount of time (about 2 seconds, but can be longer or shorter) when opening and closing.

It's worth noting that (to my eyes) the delay is the exact same while opening and closing.

This delay is the exact same when using vim -u NONE which, to me, implies this isn't an issue with my plugins.

I've tried startup profiling but nothing jumped out to me, though this could just be me not knowing what to look for. EDIT: I've confirmed that the delay happens before Vim starts, meaning that any vim profiling I do is irrelevant.

I was just going to deal with this until I found a big clue: Setting t_ti="" and t_te="" almost completely got rid of the delay!

This has the unfortunate side effect of not returning my terminal to what it looked like before opening Vim, which, unfortunately, is a deal breaker for me.

With all of this information, does anyone have any idea how I might diagnose/fix this?

I'm happy to add additional diagnostics, please just let me know what you'd find useful. I also have some recordings demonstrating this behavior that I could share.

System information:

Remote OS: Ubuntu 16.04.6 LTS
Local OS: Windows 10
Local emulator: Cmndr ( https://cmder.net/ )
Remote terminal: xterm (I manually set this so that my terminal is retained after exiting vim)

Remote vim install info:

VIM - Vi IMproved 8.1 (2018 May 18, compiled Oct 31 2018 12:22:50)
Included patches: 1-501
Compiled by user@host
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl               +extra_search      +mouse_netterm     +tag_old_static
+arabic            +farsi             +mouse_sgr         -tag_any_white
+autocmd           +file_in_path      -mouse_sysmouse    -tcl
+autochdir         +find_in_path      +mouse_urxvt       +termguicolors
-autoservername    +float             +mouse_xterm       +terminal
+balloon_eval      +folding           +multi_byte        +terminfo
+balloon_eval_term -footer            +multi_lang        +termresponse
+browse            +fork()            -mzscheme          +textobjects
++builtin_terms    +gettext           +netbeans_intg     +timers
+byte_offset       -hangul_input      +num64             +title
+channel           +iconv             +packages          +toolbar
+cindent           +insert_expand     +path_extra        +user_commands
+clientserver      +job               -perl              +vartabs
+clipboard         +jumplist          +persistent_undo   +vertsplit
+cmdline_compl     +keymap            +postscript        +virtualedit
+cmdline_hist      +lambda            +printer           +visual
+cmdline_info      +langmap           +profile           +visualextra
+comments          +libcall           -python            +viminfo
+conceal           +linebreak         +python3           +vreplace
+cryptv            +lispindent        +quickfix          +wildignore
+cscope            +listcmds          +reltime           +wildmenu
+cursorbind        +localmap          +rightleft         +windows
+cursorshape       -lua               -ruby              +writebackup
+dialog_con_gui    +menu              +scrollbind        +X11
+diff              +mksession         +signs             -xfontset
+digraphs          +modify_fname      +smartindent       +xim
+dnd               +mouse             +startuptime       +xpm
-ebcdic            +mouseshape        +statusline        +xsmp_interact
+emacs_tags        +mouse_dec         -sun_workshop      +xterm_clipboard
+eval              -mouse_gpm         +syntax            -xterm_save
+ex_extra          -mouse_jsbterm     +tag_binary
   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: "/usr/local/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/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2   -g -O2 -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 -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lnsl  -lselinux  -ldl     -L/usr/lib/python3.5/config -lpython3.5m
Brandon Sturgeon
  • 29
  • 4
  • 1
    Vim can edit files over ssh, which is usually a much faster transfer (screen drawing is slow over the wire), and it lets you edit with your settings and such in place. Give it a go (see :help netrw) – D. Ben Knoble Apr 07 '20 at 13:22
  • @D.BenKnoble Thanks for the info! Unfortunately this doesn't fit my workflow. I'd likely have to set up a local VM to make something like that work (setting up vim with my preferred settings on windows could be a pain), and that isn't ideal for my situation.

    I will, however, give it a shot to see if it makes a difference with the issue I'm describing.

     – Brandon Sturgeon Apr 07 '20 at 18:42
  • It looks to me that the issue is that your terminal emulator (Cmder) is not really compatible with the TERM=xterm setting. Are you sure that's the one you should be using? Can you try a different terminal emulator or SSH client (perhaps PuTTY?) and see if you have the same issue there? I looked at the Cmder website and I didn't see any mentions of which TERM it supports (which is not totally surprising, given it's primarily a Windows command terminal...) Anyways, I suggest you look in that direction. – filbranden Apr 08 '20 at 04:22

1 Answers1

1

If $DISPLAY is (incorrectly) set in your SSH environment, then Vim may be timing out trying to connect to an X server that doesn't exist. It does this for functionality like copying to/from the X selections.

You can verify this in a couple of ways.

  1. Check if vim -X removes the delay
  2. Use vim --startuptime to see details about what Vim does when starting up.

The benefit of 2. is that you not only can verify whether the delay is due to the X connection (time will show up in the clipboard setup line item), but you can see what else might be affecting your startup time.

jamessan
  • 11,045
  • 2
  • 38
  • 53