Toggling rnvimr after switching to buffer in different directory than last opened file retains artifacts from previous directory

[acziryak]

• nvim --version:
• Operating system/version:
• nvim +'checkhealth rnvimr':

NVIM v0.9.4
Build type: Release
LuaJIT 2.1.1696795921

MacOS Ventura 13.4

1
  1 ──────────────────────────────────────────────────────────────────────────────
  2 rnvimr: health#rnvimr#check
  3
  4 OS
  5 - OK Name: Mac
  6
  7 Ranger
  8 - OK Version: ranger 1.9.3
  9
 10 Python
 11 - OK Version: 3.11.6 (main, Oct  3 2023, 02:51:45) [Clang 14.0.3 (clang-1403.0.22.14.1)]
 12
 13 Pynvim
 14 - OK Version: 0.4.3
 15
 16 Ueberzug (optional)
 17 - Ueberzug is not support for Mac
 18
 19 RPC
 20 - OK RPC echo: Neovim send "Give me five!" and receive "Give me five!"

Describe the bug

Toggling rnvimr after switching to buffer in different directory than last opened file retains artifacts from previous directory.

Successfully reproduced using mini.vim.

Steps to reproduce the behavior:

1. Open file in nvim
2. Split window
3. Use :RnvimrToggle
4. Navigate to different directory (best exemplified in at least several levels higher or lower and sideways)
5. Open a file within that directory in new buffer
6. Switch back to first buffer
7. Use :RnvimrToggle to open ranger
8. Observe that directory of new buffer is shown - the previous location that ranger was used.
9. Try using j or k to move up or down within that directory, and observe that the files of the first directory are displayed as highlighted
10. Use R (or reload_cwd) to refresh ranger, and see that directory now shows first buffer's directory.

To rephrase - it appears that it is in fact in the new directory, however the artifacts from the previous directory remain, and only a refresh will show me the details of where ranger actually is.

Expected behavior

I expect ranger to show the details of the directory in which ranger is currently without a manual refresh.

Additional context

Something interesting to me is that as long as ranger needs to redraw something - file name, file contents, etc. - it is able to successfully overwrite it and redraw it. But sections of the window that never have to get redrawn never disappear. They just hang around in their entirety. That includes the path of the filesystem on the top of the window, and the file preview space. Anything that I don't specifically find a way to cause a redraw of just retains the artifacts of the previous working directory.

[kevinhwang91]

I don't know how to reproduce this issue.