0

I recently started to use netrw as a file manager next to my editing session. But I had a coupe of issues with it.

First of all netrw reads unhidden buffers from the disk every time. Which made me lose changes when I left a file (without writing it) and then came back to it. Therefore I needed to set hidden. (Not sure whether that is correct but I did not investigate further.)

But now I have an issue with :wall. Let's say I have these two files:

echo foo > foo
echo bar > bar
echo foobar > fooba

I open one of them with

vim -u ~/.testvimrc foo

Where .testvimrc looks as follows:

let g:netrw_liststyle=3
let g:netrw_chgwin=2
let g:netrw_winsize=22
set nocompatible
set hidden
set noautowrite

I edit foo do not write it. And open netrw:

:22Lexplore

And open the bar file using the netrw window. I then edit bar and do not write it either. I notice that I forgot the r in the last file fooba, therefore I go into the netrw window (<c-w><c-w>) and press R to rename the file fooba -> foobar.

Finally I do:

:wall

To write everything but then Vim writes an extra file. The final file listing looks as follows:

bar
foo
foobar
NetrwTreeListing 1

This only happens when I have netrw configured. If I comment the netrw lines out:

"let g:netrw_liststyle=3
"let g:netrw_chgwin=2
"let g:netrw_winsize=22
set nocompatible
set hidden
set noautowrite

And perform the same procedure I do not get the NetrwTreeListing 1 file.


This is a MCVE, in a real world editing I often get dozens of those NetrwTeeListing * files after a session of editing ans renaming files.

I am confident I'm configuring netrw wrong. I have been using it just for a couple of days, so I'm a little clueless on its configuration. On the other hand I'm confident that the netrw listings are readonly buffers, therefore :wall shall not be writing them (contrary to :wall!).

What I'm doing wrong? I'm tired of removing those NetrwTreeLisitng * files after an editing session.


Extra note: I renamed my ~/.vim directory for the MCVE (mv ~/.vim ~/.old-vim) to make sure plugins are not interfering.


Update

It does look like a bug. A new buffer is created every time a refresh happens on the tree listing (let g:netrw_liststyle=3) in netrw.vim. The refresh happens in s:NetrwRefresh, specifically in the lines 8502-8507 (in the newest netrw available):

sil! NetrwKeepj %d _
if a:islocal
 NetrwKeepj call netrw#LocalBrowseCheck(a:dirname)
else
 NetrwKeepj call s:NetrwBrowse(a:islocal,a:dirname)
endif

If I enter netrw in tree list mode and hit any command that triggers a refresh (R, r, D) that code runs and produces a modified buffer. The output of :buffers! after a refresh looks as follows:

:buffers!                           
  1 #a   "foo"                          line 0
  2u h + "NetrwTreeListing 1"           line 1
  4u%a-  "NetrwTreeListing 2"           line 8
  5u     "NetrwTreeListing"             line 1

Note the h + next to the old listing. I'm continuing the investigation. (I'm using this question as a scratch pad for notes about the issue)

  • netrw is, err, special code. Consider posting a bug report to vim_dev. – Sato Katsura Jul 17 '16 at 17:48
  • @SatoKatsura - I thought netrw was maintained separately, but it actually is in the main Vim repository. I guess, that, if no one has a similar issue I'll need to open a bug report and try to debug it myself. – grochmal Jul 17 '16 at 18:11
  • 1
    You should ask those issues the maintainer of the file, but first test the latest version – Christian Brabandt Jul 17 '16 at 19:21
  • Report sent to vim_dev and to the maintainer of netrw (I believe at least, since I did not get a delivery failure), I'll keep the question updated as thing go forward. – grochmal Jul 17 '16 at 23:09
  • I didn't see a message in vim_dev and also the moderation queue is empty. So it looks like it never appeared – Christian Brabandt Jul 18 '16 at 5:47

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.