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.
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
ig:netrw_maxfilenamelento a larger numberlet 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?