-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No buffer shown for netrw #25
Comments
It uses the buffer number, not the buffer name. So I have no idea how this situation can happen. What does |
|
Ohhh, I think I remember now… this is one of these bizarro aspects of netrw. When you open a directory, netrw creates an unlisted unnamed alternative buffer for it and renders the directory into that buffer, and then (if I still have the details right) intercepts switches into the regular (and named) buffer and flips you over to the rendered version in the alternative buffer. This is not something that can be handled without specific support for netrw… and I think I didn’t find a way to detect it reliably at the time (my memory is really hazy at this point…). I vaguely remember this being among the things that drove me to write readdir (“gee, this has to be doable in a less crazy way”). Edit: jinx… |
Okay, that would make sense, so netrw is in buffer 4 but is randomly also working in buffer 5 somehow? If you're saying the easiest way to fix this is to use readdir, then fair enough, I'll try it out! |
Well buffer 4 has the directory name but there is nothing in it. And buffer 5 has no name and is not listed but has the directory contents in it. And when you switch to buffer 4, netrw forces you into buffer 5. I must admit that after having written readdir and run into the same design issues, I can now appreciate why netrw chose this design. I addressed those issues by modifying the buffer name instead, but that creates a variety of other design problems that I then had to work around. I’m not wild about either design. The fundamental problem is that in Vim, no two buffers can have the same name. So if you render a directory into the buffer directly named after the directory, you cannot have two directory browser buffers showing the same directory. E.g. if you are browsing your home directory in one buffer and In readdir I reacted to this by setting In netrw they solved all this by doing this alternative unlisted buffer dance instead. In some ways this is less crazy – using multiple buffers isolates the state of each of them, so it’s simpler and more robust compared to readdir, which has to carefully track each bit of buffer state that it relies on. But the netrw bodge is also more visible to the user. Both approaches suck in different ways. But under Vim’s constraint that buffer names must be unique, I can’t think of any better alternative. |
Hmm, could you just switch buffers when the user tries to cd into a directory that is already open in another buffer? If I have Buffer 1 open at Also, in |
You can hit o on a file to open it in a new buffer, or t to open it into a new tab. Other operations are not yet supported but I intend to add them. Switching buffers does work – it’s what readdir does when you try to open an already-open file. But I found it rather disorienting for directories, because your navigation actions suddenly affect a different directory browser than the one you started with. It would only make sense if you could never change directory within a browser but only open directories, as new buffers. That would make some amount of sense, even… but navigating around your filesystem would quickly accumulate lots of open directory buffers. Dunno if that would really be usable. |
Say I have the following directory listing:
I open everything with
vim *
:I get my files and the
dir/
listing as expected. But if I change to the dir buffer, thedir/
option in the tabline isn't highlighted.I assume this is because that buffer is listed as "no name". Is this something that's actually possible to fix? If there's no buffer name, I can imagine that with multiple directories open it might not be possible to work out which was highlighted.
The text was updated successfully, but these errors were encountered: