[vim/vim] netrw opens empty buffer instead of actual file contents (#3276)

[lucianposton]

1. let g:netrw_browse_split=4 in .vimrc
2. let g:netrw_liststyle=3 in .vimrc
3. open netrw in a directory that contains two files each in separate directory/subdirectory
4. expand the directories of both dirs containing the two files in netrw
   1. Important step to repro
   2. If instead this step is done immediately prior to step 7, the first attempt to expand the dir will fail, requiring the user to press twice on the same dir to expand it in netrw.
5. open 1st file by selecting and pressing
6. close buffer to return to netrw
7. attempt to open 2nd file by selecting and pressing

Expected: 2nd file contents is loaded into new buffer

Actual: an empty buffer is shown. See gif containing repro below:

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

[Bruno]

I am facing both these same issues. I have the same options set. I had twice to open folders like above. In my case the first would close a sibling folder. Another detail I noticed:
0. Lets say I have Lexplore toggled on. And I have the options set as above.

1. Lets say i have directory Home

2. Home has 2 subdirectories. Directory A and Directory B. And each has a text file.
   HOME
   | A/
   | a.txt
   | B/
   | b.txt

3. If I haven't opened any files yet and I open a.txt through netrw it is successful. But when I go back to the netrw and on b.txt it creates a new empty buffer with filename A/b.txt . This tells me it creates a new file in the same directory as the parent directory of the file open on the right side window.
   I can maybe create a vid/gif like above to show this if needed.

[Daniel Sockwell]

I am also having this issue.

[Frank Lyder]

I have a similar problem. And I've found a very simple replication of the bug (and workaround):

1. Open any file in one folder
2. Open any file in another folder

What happens at step two is that it tries to open a file with the given name you selected but at the wrong folder (the same folder as you opened the other file).

3. Try to open the same file again.

Now it opens the correct file in the correct folder.

So just trying to open up the same file twice lets you finally open the correct file. But leaves open empty buffers having opened a file not existing but with the same name in another folder

[Jérémie C. Wenger]

Same issue here. I reckon this comes from the fact that netrw was built to work without the expanding folder mechanism, meaning that if you want to open a file in another directory, you will have to move there, leading netrw to update the directory in the process. What happens now, so far as I can see, is that because you don't open or select the new directory before selecting the file, it appends the file name to the current dir, leading to the default behaviour, creating a new buffer with that name, as can be seen in the statusline. TheKnarf's solution works bc what seems to happen is that even if the new empty file opens in the old dir, netrw still updates the dir to the new one, so the next time you select the file you're in the right place. Another workaround is to close/open the other fir before opening the file, which defeats the purpose of this option, unfortunately.

[cecamp]

Closed #3276.

[cecamp]

I see the problem and will try to fix it tomorrow (Feb 18) -- cec

[Sam Wilson]

Was just stopping by to report the same thing and saw it is closed, but that there's an indication is will still be fixed, which seems ambiguous. Let me know if there's a way to help test/verify that any fix works. Happy to help.

[Jérémie C. Wenger]

Works now like a charm, thanks!

[Bram Moolenaar]

> Works now like a charm, thanks!

What do you mean with "now"? Did you fetch another version of netrw?

--
Engineers understand that their appearance only bothers other people and
therefore it is not worth optimizing.
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Jérémie C. Wenger]

Well, yes. I had installed vim 8 by adding this repo: ppa:jonathonf/vim (as described here) not too long ago, and when I saw @cecamp's note I thought I'd do an upgrade with apt-get just to try, and now the issue has vanished, I can switch between files in different folders without empty buffers.

Works now like a charm, thanks!
What do you mean with "now"? Did you fetch another version of netrw?
…
-- Engineers understand that their appearance only bothers other people and therefore it is not worth optimizing. (Scott Adams - The Dilbert principle) /// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\ \\ an exciting new programming language -- http://www.Zimbu.org /// \\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

[K.Takata]

What is your version of netrw?
Netrw was once updated to v162, but it had some problems. So it was reverted to v156.
If you used slightly old version of vim 8, netrw v162 might be bundled.

[Jérémie C. Wenger]

Just checked in my /usr/share/vim/vim81/autoload/netrw.vim, it's v156.

[George Tsopanoglou]

I still experience this exact issue on v165, vim8.1 macOS version (1 - 1900)

[Christian Brabandt]

you can help fixing this by performing the steps mentioned at :h netrw-debug.

[drakuno]

Hello.

I am having this problem.

I followed the h: netrw-debug steps. You can find the results here: https://gist.github.com/drakuno/978224d0250ab3660c7ad83be4fcbbd7

An issue while debugging was that upon running vim -u netrw.vimrc --noplugins -i NONE . I got the following errors:

Error detected while processing VimEnter Autocommands for "*"..function <SNR>3_VimEnter[16]..<lambda>1[1]..<SNR>3_LocalBrowse[32]..script /home/drakuno/.vim/autoload/netrw.vim:
line   56:
E492: Not an editor command: DechoRemOn
Press ENTER or type command to continue
Error detected while processing VimEnter Autocommands for "*"..function <SNR>3_VimEnter[16]..<lambda>1[1]..<SNR>3_LocalBrowse[32]..netrw#LocalBrowseCheck[15]..Dredir[29]..VimEnter A
utocommands for "*"..function <SNR>3_VimEnter[16]..<lambda>1[1]..<SNR>3_LocalBrowse[32]..netrw#LocalBrowseCheck[15]..Dredir:
line   22:
E930: Cannot use :redir inside execute()
Press ENTER or type command to continue
Error detected while processing VimEnter Autocommands for "*"..function <SNR>3_VimEnter[16]..<lambda>1[1]..<SNR>3_LocalBrowse:
line   32:
E171: Missing :endif
Press ENTER or type command to continue
Error detected while processing VimEnter Autocommands for "*"..function <SNR>3_VimEnter:
line   16:
E171: Missing :endif
Press ENTER or type command to continue

—
You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.

[Charles Campbell]

drakuno (Vim Github Repository) wrote:
>
> Hello.
>
> I am having this problem.
>
> I followed the |h: netrw-debug| steps. You can find the results here:
> https://gist.github.com/drakuno/978224d0250ab3660c7ad83be4fcbbd7
>
> An issue while debugging was that upon running |vim -u netrw.vimrc
> --noplugins -i NONE .| I got the following errors:
>
> |Error detected while processing VimEnter Autocommands for
> "*"..function
> <SNR>3_VimEnter[16]..<lambda>1[1]..<SNR>3_LocalBrowse[32]..script
> /home/drakuno/.vim/autoload/netrw.vim: line 56: E492: Not an editor
> command: DechoRemOn Press ENTER or type command to continue |

|Hello:

The problem here is that you don't have the Decho.vim plugin; that's the
first step in :help netrw-debug. Did you download Decho.vba.gz, then
type :so % ? It should put its components in your personal .vim/
directory automatically.

Regards,
Chip Campbell
|

[cecamp]

I cannot seem to reproduce the problem; I'm using netrw v172d which is available at my website. I'm also using vim 8.2.3719 .

—
You are receiving this because you are subscribed to this thread.

[cecamp]

I also replied to your problem on vimdev; since you may not see that: the "Not an editor command: DechoRemOn" appears because you don't seem to have the Decho plugin. That's step#1 in :help netrw-debug. Or, if you have it (Decho.vba.gz), you haven't succefully done "vim Decho.vba.gz" then ":so %". DechoRemOn is a command provided by that plugin.

—
You are receiving this because you are subscribed to this thread.

[drakuno]

@cecamp I most definitely have the Decho plugin installed. I followed the steps thoroughly. I got the plugin from this link https://www.vim.org/scripts/script.php?script_id=120

If anything, I might have a different version.

Also, I have vim 8.2.3565 and netrw v171 (Last change 2021 Aug 16).

I forgot to mention the DBG I posted has a few separators:
Lexplore, tree-view, expand-dir-1, expand-dir-2, open-file-1 and open-file-2

Opening the second file fails: it opens a blank buffer for file2 in dir 1, when the instruction should be to open file 2 in dir 2.

I used P to open the files in my working window.

—
You are receiving this because you are subscribed to this thread.

[cecamp]

Try getting Decho.vim from my website which is more up-to-date than vim.org's. If that doesn't fix the DechoRemOn issue, then somehow vim isn't loading Decho.vim.
And, back to your procedure: What do you use to get back to the netrw window? I used :Rex, but you didn't state. Using P and Lexplore together like that seems odd; Lexplore's purpose is have a netrw that remains open. I was able finally to get an empty buffer. Seems to me that the problem is that P is overriding Lexplore's purpose; it should not be overwriting the Lexplore window. I'll try to fix that and then see if the empty buffer on the second open persists.

—
You are receiving this because you are subscribed to this thread.

[Corosan]

I've faced with the same issue, even after updating netrw up to the latest 174b version. The scenario is trivial:

1. let's get simplest file structure: > touch f1; touch f2; mkdir d; touch d/f3
2. open vim with the current dir, netrw shows f1, f2, d. Open f1 in neighbor window with 'v'.
3. Open f2 with 'P' - all looks good.
4. Go into 'd' directory inside netrw.
5. Open f3 with 'P' - it tries to open it in previous (local to buffer) directory where f1 and f2 located. Fail - new 'f3' file going to be created near f1 and f2.

After installing Decho and diving into its output I've found that:

1. NetrwPrevWinOpen() initializes local variable "curdir" with local buffer "netrw_curdir" which points to "d" dir in the scenario above, step 4. Good.
2. Then it for some reason calls NetrwTreeDir() and uses it's result to rewrite "curdir" variable. Maybe NetrwTreeDir() is needed for some fancy things, I don't know.
3. But at the beginning this function contains a short-cut statement "if exists("s:treedir") && exists("s:prevwinopen")" which evaluates to true because prev win is open and s:treedir has been set also to a root directory. So it's returned. Without any 'd'.

My local fix is to comment out the whole statement "if exists("s:treedir") && exists("s:prevwinopen") ... endif" in NetrwTreeDir(). Not sure, what it's supposed to optimize, but files are able to be opened after this.

Hope my post sheds light on this long-standing issue and will help original author to understand the reasons and how to fix it more correctly.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/3276/1694336907@github.com>