I use Cygwin's vim & gvim. I used to be able to do as follows. Consider this file mk.bash, with no right-padding spaces:

// mk.bash
// -------
javac \
-classpath "/c/Program Files/MyJarFile.jar" \

I used to press ctrl-V on the very 1st character, then cursor down to the last character. All the text becomes highlighted to show that is is selected. I then yank it into register a using "ay. I can then paste an accurate copy in another Vim subwindow, tab, file, and/or buffer.

enter image description here

I also used to be able to press ctrl-V on the very 1st character, cursor down to last character of last line, then continue cursoring right. When I cursor beyond the last character, the highlighting would change into a rectange, upper left corner on 1st character of the file and lower right corner at the cursor.

enter image description here

If I yank into register a and paste, only the highlighted text would insert, and it included right padding with spaces to ensure a rectangular block of text was pasted.

Because of work place restrictions, I hadn't upgraded Cygwin in a long time. When I recently had a chance to, however, I found that the ctrl-V yanking behaviour changed. My work flow is now disrupted. Specifically, the first highlighting above without right padding still looks the same, but when I paste the yanked text, it is all right-padded with spaces so that each line length is as long as the longest line -- plus one space.

For bash, the terminating \ on a line indicates that a command continues to the next line. With the extra space after \, however, it is no longer valid. Hence, I am unable to simply paste visually selected text to an xterm after yanking into register * (the system/OS cut & paste buffer).

What would cause vim to change its behaviour to right-pad like this? Is this hard-coded into vim, or is it a setting? I'm wondering if recent changes to my vimrc might be the cause. I am always changing my vimrc.

:ver output

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Mar 30 2020 21:51:17)
Included patches: 1-486
Modified by <[email protected]>
Compiled by <[email protected]>
Huge version with GTK3 GUI.  Features included (+) or not (-):
+acl               +cmdline_hist      +ex_extra          +keymap            -mouse_gpm         +persistent_undo   +spell             +timers            +X11
+arabic            +cmdline_info      +extra_search      +lambda            -mouse_jsbterm     +popupwin          +startuptime       +title             -xfontset
+autocmd           +comments          -farsi             +langmap           +mouse_netterm     +postscript        +statusline        +toolbar           +xim
+autochdir         +conceal           +file_in_path      +libcall           +mouse_sgr         +printer           -sun_workshop      +user_commands     +xpm
-autoservername    +cryptv            +find_in_path      +linebreak         -mouse_sysmouse    +profile           +syntax            +vartabs           +xsmp_interact
+balloon_eval      +cscope            +float             +lispindent        +mouse_urxvt       +python/dyn        +tag_binary        +vertsplit         +xterm_clipboard
+balloon_eval_term +cursorbind        +folding           +listcmds          +mouse_xterm       +python3/dyn       -tag_old_static    +virtualedit       -xterm_save
+browse            +cursorshape       -footer            +localmap          +multi_byte        +quickfix          -tag_any_white     +visual
++builtin_terms    +dialog_con_gui    +fork()            +lua/dyn           +multi_lang        +reltime           -tcl               +visualextra
+byte_offset       +diff              +gettext           +menu              -mzscheme          +rightleft         +termguicolors     +viminfo
+channel           +digraphs          -hangul_input      +mksession         +netbeans_intg     +ruby/dyn          +terminal          +vreplace
+cindent           +dnd               +iconv             +modify_fname      +num64             +scrollbind        +terminfo          +wildignore
+clientserver      -ebcdic            +insert_expand     +mouse             +packages          +signs             +termresponse      +wildmenu
+clipboard         +emacs_tags        +job               +mouseshape        +path_extra        +smartindent       +textobjects       +windows
+cmdline_compl     +eval              +jumplist          +mouse_dec         +perl/dyn          +sound             +textprop          +writebackup
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "/etc/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: "/etc"
 f-b for $VIMRUNTIME: "/usr/share/vim/vim82"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/uuid -I/usr/include/harfbuzz -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -D_REENTRANT    -ggdb -O2 -pipe -Wall -Werror=format-security -fstack-protector-strong --param=ssp-buffer-size=4 -fdebug-prefix-map=/usr/src/ports/vim/vim-8.2.0486-1.x86_64/build=/usr/src/debug/vim-8.2.0486-1 -fdebug-prefix-map=/usr/src/ports/vim/vim-8.2.0486-1.x86_64/src/vim-8.2.0486=/usr/src/debug/vim-8.2.0486-1 -fstack-protector-strong -D_REENTRANT  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L. -fstack-protector-strong  -L/usr/local/lib -Wl,--as-needed -o vim.exe   -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lintl  -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm    -lncursesw -lcanberra  -liconv -lacl -lattr -lintl   -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--enable-auto-image-base -fstack-protector-strong  -L/usr/lib/perl5/5.30/x86_64-cygwin-threads/CORE -lperl -lpthread -ldl -lcrypt
  • This seems to be happening because 'virtualedit' is set. If you unset it, then when you paste an uneven virtual block on lines that are empty, it won't pad the lines with spaces. But it will do that when it's set. (But note you do need 'virtualedit' set to select the second rectangle...)
    – filbranden
    Commented Sep 5, 2020 at 6:34
  • 1
    @filbranden: Thanks, filbranden. I confirmed what you said. However, I've always been able to cursor around in Normal mode regardless of where a line actually ended. So I must have had virtualedit=all. I'm beginning to think that yanking in visual mode has changed. Before, exactly the highlighted text was yanked, and this applied to both pictures in my original post. Now, it does not apply to the 1st picture Commented Sep 5, 2020 at 6:47
  • I turned it into an answer. I guess it's possible that Vim behavior has changed regarding copying a Visual Block with virtualedit enabled... But I glanced at the commits that mention virtualedit and none seems to touch this area.
    – filbranden
    Commented Sep 5, 2020 at 7:07
  • I’m a bit confused by your first scenario. Did you mean to write Shift-V for the first one, or do you really press Ctrl-V in both situations?
    – Rich
    Commented Sep 5, 2020 at 7:10
  • I pressed Ctrl-V for both images shown in the posted question. I didn't mention in my last comment, but virtualedit=all. Otherwise, it's too constraining. Commented Sep 5, 2020 at 13:57

1 Answer 1


The behavior you're describing is consistent with yanking a Visual Block when the 'virtualedit' option is set to block or all.

There's a hint that you have this option enabled from your second screenshot, since you mentioned that the lines in your test sample have no right-padding spaces, and yet the lower right end of your rectangular Visual Block selection is eight spaces beyond the end of the line, which would only be possible if 'virtualedit' is set.

I can't tell what changed in your setup that triggered that change... The 'virtualedit' option was introduced a long time ago, before Vim 7. But according to the documentation, before version 8.1.826 the compile-time option +virtualedit could be disabled at compile time, while starting at that version it became mandatory. So if the Cygwin build for Vim was a small or minimal build, it's is possible that it lacked this setting before the upgrade.

That doesn't fully explain it though, since the option default is disabled and if you had some config that was setting it on a build without the compiled option, it would most likely produce a syntax error... Well, except if it was being set in a block that checked for the feature with has('+virtualedit'), in which case that block of config became active with the new version. (I speculate here, but it's a possible explanation.)

If you're not aware of what is enabling the 'virtualedit' option, you can use the following command to find out the source file and line where it's actually set:

:verbose set virtualedit?

In order to solve this issue, you can simply set it back to empty. Though you'll not be able to select the exact rectangle from your second snapshot of you unset it... If you're interested in both use cases, you might want to consider adding mappings to toggle the option on or off, so you can get the best of both worlds.

  • 1
    At first, I thought that we must be missing something. I found ye olde laptop with a 2015 Cygwin installation, figured out how to start the right X-windows script, and tried very hard to get the behaviour that I recalled. Nada. The best I could do was use v to start visual, and that doesn't right pad. Neither does it remove left padding, as deceptively shown in the 1st image of the posted question. This was Vim 7.4, dated 2013-08-10 and compiled 2015-05-20. Could it be that it is a false memory? How can it be so clear? I blame age. Thank you again, filbranden. Commented Sep 5, 2020 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.