Skip to content
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

Renaming a file open in a hidden buffer blanks the buffer #371

Closed
ealang opened this issue Oct 3, 2021 · 14 comments
Closed

Renaming a file open in a hidden buffer blanks the buffer #371

ealang opened this issue Oct 3, 2021 · 14 comments
Labels
bug Something isn't working

Comments

@ealang
Copy link
Contributor

ealang commented Oct 3, 2021

Hi, thanks for the great plugin!

I came across one issue with renames and hidden buffers. If you rename a file open in a hidden buffer, then navigate back to the buffer, the buffer is now empty until you reload it (e.g. with ":e"). Runs the risk of accidentally writing the empty buffer to disk. The buffer appears to get renamed correctly, but the contents are gone. No issue with visible buffers.

@lambdalisue
Copy link
Owner

Please write a step by step procedure to reproduce your situation.

@ealang
Copy link
Contributor Author

ealang commented Oct 3, 2021

Vanilla Neovim v0.5.0 + latest Fern

  1. echo hello > hello.md
  2. nvim hello.md
  3. :Fern .
  4. Rename to hello2.md
  5. Still in Fern, open hello2.md
  6. Note buffer is blank
  7. :e to restore contents

@lambdalisue
Copy link
Owner

Thanks for the procedure. Unfortunately, I could not reproduce your situation with that procedure.

Kapture.2021-10-09.at.17.51.18.mp4

Please provide me a minimal vimrc to reproduce the situation. Please make it minimal

@ealang
Copy link
Contributor Author

ealang commented Oct 9, 2021

Oh, that is puzzling. Thanks for looking into this. I ran my test with neovim + Fern (ed2e422) with an empty init.vim and no other plugins installed. I also tried vim with the same result.

I started digging into this a bit last week. ealang@1e20482

I noticed removing set hidden makes the problem go away. Maybe worth noting that if set hidden is already present in vimrc, the issue disappears.

My thinking was that with nohidden by default, the hello.md buffer gets unloaded, then with hidden turned on vim might assume the buffer still has content. I didn't know what purposes set hidden serves in that function. My commit definitely breaks a case where nohidden is on, but you :hide a buffer with modifications (results in Fern getting an E37 when trying to switch away from the buffer after running file).

I hit the same issue with these steps (mimics what Fern is doing):

  1. echo hello > hello.md
  2. nvim hello.md
  3. Switch to a new buffer and close buffer 1
  4. :!mv hello.md hello2.md
  5. :set hidden
  6. :1buffer
  7. Note buffer is blank
  8. :file hello2.md
  9. :2buffer
  10. :set nohidden
  11. :1buffer
  12. Buffer is still blank, get E13

@lambdalisue lambdalisue removed the could not reproduce The issue is not reproducable label Oct 12, 2021
@lambdalisue
Copy link
Owner

Reproduced. I'll investigate.

@lambdalisue
Copy link
Owner

My thinking was that with nohidden by default, the hello.md buffer gets unloaded, then with hidden turned on vim might assume the buffer still has content. I didn't know what purposes set hidden serves in that function. My commit definitely breaks a case where nohidden is on, but you :hide a buffer with modifications (results in Fern getting an E37 when trying to switch away from the buffer after running file).

Your change (set bufhidden=hide) seems ok. How do you get E37 if you applied that change?

@ealang
Copy link
Contributor Author

ealang commented Oct 13, 2021

If I make some changes (again with nohidden in vimrc) in a buffer without saving, and run:hide, then when Fern later tries to leave the buffer it gets E37. Using buffer! seems to keep the modifications and allow the buffer switch.

Opened #373

@lambdalisue
Copy link
Owner

If I make some changes (again with nohidden in vimrc) in a buffer without saving, and run:hide, then when Fern later tries to leave the buffer it gets E37. Using buffer! seems to keep the modifications and allow the buffer switch.

I'm sorry I don't get it. Could you write step by step procedure to reproduce E37? I'd love to know if that's normal situation or so on.

@ealang
Copy link
Contributor Author

ealang commented Oct 13, 2021

Getting an E37 without the buffer! in my pr:

  1. Open two buffers
  2. Make some changes in one of them (don't save)
  3. :hide the buffer with changes
  4. Rename the file that has the changes

Fern will fail to run keepjumps keepalt %dbuffer due to the E37, can see it in :messages.

It doesn't seem like a normal situation, but idk. I didn't know it was possible until I read the :help buffer entry:

The commands that move through the buffer list sometimes make a
buffer hidden although the 'hidden' option is off ...

@lambdalisue
Copy link
Owner

lambdalisue commented Oct 16, 2021

I actually hadn't really understood the behavior of :hide command. Now I got the situation thanks 👍

Well, I think it's a kind of situation that we should care... I'll think about workarounds (or anybody?)

@lambdalisue
Copy link
Owner

Getting an E37 without the buffer! in my pr:

Oops. So buffer! doesn't throw E37 right? Do you know any drawback for using buffer! there?

@ealang
Copy link
Contributor Author

ealang commented Oct 16, 2021

Oops. So buffer! doesn't throw E37 right? Do you know any drawback for using buffer! there?

Correct, with the buffer! I don't get a E37. I can't find any drawbacks based on some testing. My interpretation of the buffer-! help entry is that it will hide the buffer regardless of no/hidden option.

@lambdalisue
Copy link
Owner

I see. Ok, let's merge #373 and see what's happen then 👍

@lambdalisue
Copy link
Owner

Released as https://github.com/lambdalisue/fern.vim/releases/tag/v1.38.4
Thanks for your contribution 🎉

@lambdalisue lambdalisue added the bug Something isn't working label Oct 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants