Netrw discards changes without asking

Question

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.

---

.vimrc

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

set nocp
filetype plugin on

---

Environments

I could reproduce the problem under multiple environments.

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
      else
-      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
      endif
 "     call Decho("edit-a-file: after e! ".dirname.": hidden=".&hidden." bufhidden<".&bufhidden."> mod=".&mod,'~'.expand("<slnum>"))
      call s:NetrwCursor()
@@ -4912,7 +4922,9 @@
     else
 "     call Decho("edit-a-file: remote file: NetrwBrowse will edit it",'~'.expand("<slnum>"))
     endif
-    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.