I see an odd problem with netrw for file names that are long enough to run into the next column (which is for the file size). When I press "Return" or "o" to view the file, it gets confused by the file name. It believes that the file name is the actual file name with the file size appended to it. The resulting buffer is blank, as an actual file with such a file name does not exist. I used Bash to confirm that the actual file name does not have the file size appended to it.

enter image description here

If I use "m" to rename, it normally presents me with source and destination file names, where the destination file name defaults to the source file name and the user has to cursor over and modify the destination file name. If I try that here, both the source and default destination file names have the file size appended.

The command ":setl tabstop=60" (where 60 is much longer than the file name to avoid the clash) doesn't do anything. I used "set list" to see that the white space between the file names and the file sizes are spaces rather than tabs, which is abnormal. On another machine that doesn't exhibit this problem, netrw also shows spaces between columns rather than tabs, so I think it that this must be a recent design decision for netrw (I recall not too long ago seeing tabs). I am certain that this is not due to ":set[l] expandtab"; I removed this in /etc/vimrc and reran Gvim. The setting appears in some functions and commands, but none that I use, and none that are invoked in other functions/commands.

Launching a fresh instance of Gvim doesn't seem to avoid the problem. Upgrading my Cygwin installation seemed to solve the problem temporarily, but it came back. Reinstalling all packages did not make the problem go away. Harmonizing /etc/vimrc between the laptops (one exhibiting the problem and the other not) doesn't make the problem go away. I confirmed that both had tabstop=33. The one without the problem still has spaces between the filenames and the files sizes even if a filename is greater than 33.

Is there anything further I can do to sleuth down or eliminate the problem?

Here is my Gvim version information:

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 13 2022 22:00:24)
Included patches: 1-4372
Modified by <[email protected]>
Compiled by <[email protected]>
Huge version with GTK3 GUI.  Features included (+) or not (-):
+acl               +cmdline_hist      +ex_extra          +jumplist          +mouse_dec         +perl/dyn          +sodium            +textobjects       +wildmenu
+arabic            +cmdline_info      +extra_search      +keymap            -mouse_gpm         +persistent_undo   +sound             +textprop          +windows
+autocmd           +comments          -farsi             +lambda            -mouse_jsbterm     +popupwin          +spell             +timers            +writebackup
+autochdir         +conceal           +file_in_path      +langmap           +mouse_netterm     +postscript        +startuptime       +title             +X11
-autoservername    +cryptv            +find_in_path      +libcall           +mouse_sgr         +printer           +statusline        +toolbar           -xfontset
+balloon_eval      +cscope            +float             +linebreak         -mouse_sysmouse    +profile           -sun_workshop      +user_commands     +xim
+balloon_eval_term +cursorbind        +folding           +lispindent        +mouse_urxvt       +python/dyn        +syntax            +vartabs           +xpm
+browse            +cursorshape       -footer            +listcmds          +mouse_xterm       +python3/dyn       +tag_binary        +vertsplit         +xsmp_interact
++builtin_terms    +dialog_con_gui    +fork()            +localmap          +multi_byte        +quickfix          -tag_old_static    +vim9script        +xterm_clipboard
+byte_offset       +diff              +gettext           +lua/dyn           +multi_lang        +reltime           -tag_any_white     +viminfo           -xterm_save
+channel           +digraphs          -hangul_input      +menu              -mzscheme          +rightleft         -tcl               +virtualedit       
+cindent           +dnd               +iconv             +mksession         +netbeans_intg     +ruby/dyn          +termguicolors     +visual            
+clientserver      -ebcdic            +insert_expand     +modify_fname      +num64             +scrollbind        +terminal          +visualextra       
+clipboard         +emacs_tags        +ipv6              +mouse             +packages          +signs             +terminfo          +vreplace          
+cmdline_compl     +eval              +job               +mouseshape        +path_extra        +smartindent       +termresponse      +wildignore        
   system vimrc file: "/etc/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/share/vim"
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=/pub/devel/vim/vim-8.2.4372-1.x86_64/build=/usr/src/debug/vim-8.2.4372-1 -fdebug-prefix-map=/pub/devel/vim/vim-8.2.4372-1.x86_64/src/vim-8.2.4372=/usr/src/debug/vim-8.2.4372-1 -fstack-protector-strong -DSYS_VIMRC_FILE=/etc/vimrc -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 -lsodium -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.32/x86_64-cygwin-threads/CORE -lperl -lpthread -ldl -lcrypt 
  • I gave up on netrw and start creating "my own file manager with files and directories", wip though: github.com/habamax/vim-dir
    – Maxim Kim
    Commented Jul 12, 2022 at 5:39
  • try to change the view of the netrw with i
    – Maxim Kim
    Commented Jul 12, 2022 at 5:42
  • 3
    github.com/vim/vim/issues/10055 Try to set g:netrw_maxfilenamelen to a larger number Commented Jul 12, 2022 at 6:21
  • Thanks, Christian. That worked. One has to close the netrw window and re-open it after (say) let g:netrw_maxfilenamelen=66. In the past, however, there was a tab delimiter between the filename and the file size, which made it unnecessary to change netrw_maxfilenamelen (which one might have to do frequently, depending on the file names displayed). On a related note, I wonder why this is a problem on one system and not another, despite identical vimrc files. Did you want to post your comment as the answer? Commented Jul 12, 2022 at 17:38

1 Answer 1


It has been almost 2 years since I posed this question and the problem persists.

As per Christian Brabandt's comment, the only solution thus far seems to be (say) let g:netrw_maxfilenamelen=66. You may have to close and re-open the netrw window.

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.