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 acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.