When I

  1. Execute vim A command from shell

  2. Edit the file A in some way (now &modified == 1)

  3. Execute :Lexplore †1 to enable the side pane of netrw

  4. Press Enter on an arbitary file B

, the file B is opened in the window in which A was opened without any prompt and, as a result, the modification to A is totally lost.

Is this an expected behavior? How can I get along with this buggy behavior?

†1: Edit: it turns out the problem is not specific to :Lexplore command. Netrw opened via :Explore or :e also shows the behavior.

Current Status

I suspect the behavior is unexpected (i.e. a bug). I'm debugging netrw according to the instructions found in :help netrw and have located the cause; e! is called in autoload/netrw.vim. Just replacing two e! with e solved the discarding behavior. But I still have to keep analyzing the code to know what kind of side effects will happen if e! is replaced with e and the operation fails due to &modified == 1.


Now I'm using a minimal .vimrc which has only the following two lines.

set nocp
filetype plugin on


I could reproduce the problem under multiple environments.

  • I can reproduce it with :Lexplore and it discards the changes in A when I open B. I upgraded to latest netrw from Dr. Chip's website (netrw v170c from March 30, 2020) and I can still reproduce it. Where is the e! you said causes it? Which function?
    – filbranden
    Apr 30, 2020 at 4:13
  • 1
    @filbranden See my GitHub repository. Though I'm still writing README.md, the patch should work.
    – ynn
    Apr 30, 2020 at 4:22
  • 1
    You might want to report it upstream. See Dr. Chip's page here: drchip.org/astronaut/vim/index.html You'll probably have to send him an email, you can find his address at the top of the :help netrw page (remove the NOSPAM letters from the address there...)
    – filbranden
    Apr 30, 2020 at 4:35
  • 1
    @filbranden The patch was finally adopted in version 170f. Again, thank you for your suggestion.
    – ynn
    May 7, 2020 at 1:30
  • Awesome!!! Thanks for following up on it!
    – filbranden
    May 7, 2020 at 1:41

1 Answer 1


It seems the behavior is a bug. Here's the patch to fix it.

--- netrw_before.vim    2020-04-30 13:12:10.225394138 +0900
+++ netrw.vim   2020-04-30 13:03:50.746727412 +0900
@@ -4899,9 +4899,19 @@
      " some like c-^ to return to the last edited file
      " others like c-^ to return to the netrw buffer
      if exists("g:netrw_altfile") && g:netrw_altfile
-      exe "NetrwKeepj keepalt e! ".fnameescape(dirname)
+      try
+       exe "NetrwKeepj keepalt e ".fnameescape(dirname)
+      catch
+       echoerr "No write since last change"
+       let __local_file_opening_error = 1
+      endtry
-      exe "NetrwKeepj e! ".fnameescape(dirname)
+      try
+       exe "NetrwKeepj e ".fnameescape(dirname)
+      catch
+       echoerr "No write since last change"
+       let __local_file_opening_error = 1
+      endtry
 "     call Decho("edit-a-file: after e! ".dirname.": hidden=".&hidden." bufhidden<".&bufhidden."> mod=".&mod,'~'.expand("<slnum>"))
      call s:NetrwCursor()
@@ -4912,7 +4922,9 @@
 "     call Decho("edit-a-file: remote file: NetrwBrowse will edit it",'~'.expand("<slnum>"))
-    let dolockout= 1
+    if !exists("__local_file_opening_error")
+     let dolockout= 1
+    endif

     " handle g:Netrw_funcref -- call external-to-netrw functions
     "   This code will handle g:Netrw_funcref as an individual function reference

Note, however, the patch is written for me and not tested very well (at least by me).

See my GitHub repository to get the latest version of the patch and detailed explanations about the cause, the algorithm of the patch, etc.

I've already sent an e-mail about this bug to the author of netrw. I hope it will be fixed soon.

Update: The patch has been adopted in netrw 170f (April 30, 2020). However, I suspect it will take long for the version of netrw to be included in the upstream of vim. Till the day, if you'd like to remove the bug, manually download the plugin from the official and install it.

Your Answer

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

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