search

javigon / vim

Automatically exported from code.google.com/p/vim
0 stars 0 forks source link

netrw silently closing buffers on its own #231

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
After upgrading macvim from 7.3 to 7.4, netrw is closing buffers on its own.

What steps will reproduce the problem?
1. :Explore, navigate directories, open a file
2. :Explore, open another file
3. Buffer opened in step 1 will be closed.

What is the expected output? What do you see instead?

I expect both buffers to exist, but only the last one does.

What version of the product are you using? On what operating system?

Macvim 7.4 snapshot 73 for Moutain Lion. netrw v153i (noticed the same behavior 
with v151 so I upgraded to latest netrw)

Please provide any additional information below.

Not a problem with macvim 7.3.

Original issue reported on code.google.com by johnston...@gmail.com on 12 Jun 2014 at 6:20

GoogleCodeExporter commented 9 years ago 
I tried this with vim 7.4.320 and netrw v153i and was unable to duplicate the 
problem.  I used the following command:
  vim -u netrw.vimrc .
along with the file <netrw.vimrc>, which has two lines:

set nocp
so $HOME/.vim/plugin/netrwPlugin.vim

Please try this on your mac using the vimrc file as shown.

Original comment by drc...@campbellfamily.biz on 12 Jun 2014 at 7:36

GoogleCodeExporter commented 9 years ago 
Thanks for the quick response. Following your instructions, I too was unable to 
duplicate the problem, so I'm going to guess it's some sort of conflict with 
another plugin I'm using? I'll start adding in plugins and see what I find.

Thanks,
Lance

Original comment by johnston...@gmail.com on 13 Jun 2014 at 6:17

GoogleCodeExporter commented 9 years ago 
Looks like this was it... from my .vimrc:

if exists('+autochdir')
    set autochdir
endif

Thanks,
Lance

Original comment by johnston...@gmail.com on 13 Jun 2014 at 7:39

GoogleCodeExporter commented 9 years ago 
May I note that the buffers aren't actually closed, either.  A :ls! will show 
them.

Original comment by drc...@campbellfamily.biz on 15 Jun 2014 at 12:58

GoogleCodeExporter commented 9 years ago 
Just upgraded to os x mavericks and the latest mavericks macvim version 
(7.4.258). This release includes netrw v151. Using a minimal netrw.vimrc (only 
contains 'set nocp'). With this configuration, the originally described problem 
is back, although _only_ with remote buffers (opened via scp://...). 

So I tried upgrading netrw from 
http://www.drchip.org/astronaut/vim/index.html#NETRW, the current version of 
which is 153m. With this version and the following netrw.vimrc...

set nocp
so $HOME/.vim/plugin/netrwPlugin.vim

... there were all kinds of problems (again with remote files only... local 
files didn't seem to exhibit any issues). Attempting to open a remote directory 
results in the following:

Error detected while processing /Users/ljohnston/.vim/autoload/netrw.vim:
line  421:
E15: Invalid expression: g:netrw_keepj =! "keepj"

The remote directory opens, however, after which selecting and opening a file 
results in:

Error detected while processing function <SNR>21_NetrwBrowse..netrw#NetRead:
line  253:
E121: Undefined variable: s:netrw_silentxfer
E15: Invalid expression: s:netrw_silentxfer."!".g:netrw_scp_cmd.useport." 
".shellescape(g:netrw_machine.":".b:netrw_fnam

After which an appropriately named buffer opens, but the buffer has no file 
content.

Original comment by johnston...@gmail.com on 16 Jul 2014 at 3:41

GoogleCodeExporter commented 9 years ago 
I put v153n (netrw) on my website; this has a little more code to handle 
setting up s:netrw_silentxfer.  The problem at line 421 makes little sense; the 
initialization code for g:netrw_keepj occurs earlier.  However, given that 
s:netrw_silentxfer was not set up properly, the problem with remote browsing 
follows.
I tried scp://... and ftp://... with v153n on a Mac and had no problem.
One more thing: I used  vim -u netrw.vim --noplugins

Original comment by drc...@campbellfamily.biz on 16 Jul 2014 at 1:30

GoogleCodeExporter commented 9 years ago 
Thanks for the quick response. I tried the new version and it's much better 
than 153m, but it's not quite right. The error messages are gone now, but 
there's still some buffer weirdness. Specifically:

- If I open files via ":e scp://.../<filename>", I can keep opening additional 
file using ":e scp://..." to another specific file, and the issue never occurs. 
I can keep opening files this way and everything works as expected.
- If, however, after having opened a remote file, I browse the remote 
directory, either via ":Ex" or "e: scp://.../" and _change_ directories and 
open a file, then the previous buffer goes away. I can even ":Ex", change 
directories, ":bd", and the previous buffer goes away.

Original comment by johnston...@gmail.com on 17 Jul 2014 at 3:32

GoogleCodeExporter commented 9 years ago 
Hello!  Unfortunately, I can't seem to duplicate this behavior.

   vim -u netrw.vimrc --noplugins  scp://hostname/file
   :ls    <-- shows one file
   :e scp://hostname/dirname/
   :ls    <-- shows one file
   [select a file, press <cr>]
   :ls    <-- shows two files

The netrw.vimrc file is fairly short:
set nocp
so $HOME/.vim/plugin/netrwPlugin.vim

Please use this procedure and determine if you're still having a problem, 
because this process removes other plugins, settings, etc, from interfering.  
Also: is the procedure outlined above what you meant?

Original comment by drc...@campbellfamily.biz on 18 Jul 2014 at 5:56

GoogleCodeExporter commented 9 years ago 
Hi, thanks again for the response. You are right... the steps you describe will 
not reproduce the problem. This is definitely a finicky issue. I just spent 
some time trying to nail this down, and some of the scenarios I tried that I 
expected to reproduce the problem, and on occasion I have seen reproduce the 
problem, did not. However, I believe I've identified a series of steps that 
will reliably recreate the issue in a much simpler scenario than I'd seen 
before.

With the same setup as you describe:
set nocp
so $HOME/.vim/plugin/netrwPlugin.vim

Starting macvim with the following command:
$ mvim -u netrw.vimrc --noplugins

It's seems as though it simply requires opening three files as follows:
:e scp://hostname/vimtest/dir1/file1a.txt
:ls     <-- shows one file (file1a.txt)
:Ex
[select and open file1b.txt]
:ls     <-- shows two files (file1a.txt, file1b.txt)
:Ex
[select and open file1c.txt]
:ls     <-- ERROR, shows two files (file1a.txt, file1c.txt)

The above steps seem to reliably reproduce the issue. As an additional data 
point, the following DOES NOT reproduce the issue:

:e scp://hostname/vimtest/dir1/file1a.txt
:e scp://hostname/vimtest/dir1/file1b.txt
:e scp://hostname/vimtest/dir1/file1c.txt
:ls     <-- NO ERROR, shows all three files as expected (file1a.txt, 
file1b.txt, file1c.txt)

Hopefully the above will help you identify the problem.

Thanks,
Lance

Original comment by johnston...@gmail.com on 19 Jul 2014 at 6:33

GoogleCodeExporter commented 9 years ago 
Any news? Were you able to recreate the issue?

Original comment by johnston...@gmail.com on 9 Aug 2014 at 5:58

GoogleCodeExporter commented 9 years ago 
I've been able to duplicate the problem, so its now on my todo list.

Original comment by drc...@campbellfamily.biz on 9 Aug 2014 at 7:27

GoogleCodeExporter commented 9 years ago 
Just wondering... any progress?

Thanks,
Lance

Original comment by johnston...@gmail.com on 26 Sep 2014 at 11:27

GoogleCodeExporter commented 9 years ago 
Just downloaded the latest version, 153s. Can confirm problem still exists. In 
fact it seems to have gotten worse. Going through the above steps and doing a 
':ls' shows only a single file open in this version.

Original comment by johnston...@gmail.com on 4 Oct 2014 at 5:49

GoogleCodeExporter commented 9 years ago 
This problem was tricky to find; sorry it took as long as it did.  I think I 
have the problem fixed -- please try out the version at 
http://www.drchp.org/astronaut/vim/index.html#NETRW (v153u).
NetrwNetRead() is responsible for reading remote files; the buffer it uses 
should be "nofile", as it isn't intended to be written (locally) as named.  
Turns out the re-use of the code to create "safe" options also set the buffer 
to be "nobuflisted".  This setting caused the buffer to disappear from "ls" 
listing (althought "ls!" would still show it).  Please try it out and let me 
know if you too see the problem go away.

Original comment by drc...@campbellfamily.biz on 30 Dec 2014 at 3:18