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.

Sign up for GitHub

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

Jump to bottom

Update file handler/buffer after move/rename #308

Closed
gegoune opened this issue Apr 18, 2022 · 11 comments
Closed

Update file handler/buffer after move/rename #308

gegoune opened this issue Apr 18, 2022 · 11 comments
Labels
enhancement New feature or request

Comments

@gegoune
Copy link

gegoune commented Apr 18, 2022

Currently renaming a.lua to b.lua leaves me with open buffer named a.lua (saving which recreates a.lua on filesystem) and no b.lua gets opened.

Expected behaviour is such that a.lua buffer gets removed and b.lua is opened in its place (not with the same buffer number, but 'instead').

Originally posted by @gegoune in #47 (comment)
@nyngwang
Copy link

nyngwang commented Apr 18, 2022 •
edited
Loading

There is also a related error message shown when the cursor went back to the no-longer-exist buffer(i.e. a.lua in the example) on neo-tree close. While it is not harmful but definitely related.

@gegoune
Copy link
Author

gegoune commented Apr 18, 2022 •
edited
Loading

Without checking, afair, it's regular (neo)vim's messages saying that file for that buffer no longer exists. It's not an issue in itself as much as it is product of not updating/removing that buffer by neo-tree (which this issue is about).

@cseickel cseickel added the enhancement New feature or request label Apr 19, 2022
@cseickel
Copy link
Contributor

This is now working in main and will be in the next release.

@nyngwang
Copy link

nyngwang commented Apr 23, 2022 •
edited
Loading

@cseickel: This causes an error. The renamed buffer is not writable anymore.

E5108: Error executing lua: /Users/ningwang/.config/nvim/init.lua:35: Vim(write):E13: File exists (add ! to override)
stack traceback:
        [C]: in function 'cmd'
        /Users/ningwang/.config/nvim/init.lua:35: in function </Users/ningwang/.config/nvim/init.lua:35>
Press ENTER or type command to continue

@nyngwang
Copy link

nyngwang commented Apr 23, 2022 •
edited
Loading

:( waiting for the fix. Now it's a fake buffer that got renamed but no writable.

@cseickel
Copy link
Contributor

I'll fix it, but to be clear it's still writable and not a fake buffer at all. You just have to add the ! to your write the command the first time you write it.

:w!

cseickel added a commit that referenced this issue Apr 23, 2022
@cseickel
fix: force save of renamed buffers to prevent E13 error, fixes #308
3c27dab
@cseickel
Copy link
Contributor

cseickel commented Apr 23, 2022 •
edited
Loading

So the E13 error issue is resolved, and I also realized that previously there was no handling for renaming buffers in a directory that was renamed, that was fixed too.

I did find a new bug related to cut/pasting files. I'm not sure if it's related to this or not but I'm investigating that right now.
EDIT: That was unrelated, but it's fixed now too.

@Gelio Gelio mentioned this issue Nov 5, 2022
Merged
cseickel pushed a commit that referenced this issue Nov 5, 2022
@Gelio @cseickel
fix: delete old buffers on rename/move
5c209e5 
When renaming or moving files/directories, neo-tree used to change the
name of renamed buffers while retaining the same buffer numbers. It did
not delete the old buffers and open new ones for editing.

This ended up crashing Neovim in the following scenario:

* a `BufWritePre` autocmd was created to call
  `vim.lsp.buf.format({ async = false })`
* there was an LSP client registered for the buffer
* the buffer was opened and then put in the background (e.g. by
  `:Neotree position=current`)
* the file was renamed/moved in neo-tree

The operation that caused the Neovim crash was the `silent! write!` that
neo-tree executes on the buffer right after it is renamed. During that
write, synchronous formatting is attempted in the `BufWritePre` autocmd.

My assumption is that the LSP server does not get a notification about
the file rename and sends some invalid formatting information back to
Neovim. Neovim cannot interpret it and crashes.

The crash does not happen if the renamed buffer is currently visible,
rather than being hidden (e.g. when the renamed buffer is in one window
and neo-tree is opened in a vertical split).

The approach to handling file renamed used in this commit is the same as
used in the `vim.lsp.util.rename` [0]. Instead of reusing the buffers in
Neovim before and after rename, neo-tree deletes old buffers for the
file paths before the rename, and opens new buffers for files after the
rename. If old buffers were shown in some Neovim window, the code opens
the new buffers in these windows.

The code that handles modified buffers during rename calls `silent!
write!` on the new buffers. This no longer crashes Neovim. The downside
is that LSP clients are not attached at the moment `write!` is called,
which means the files after the rename will not be formatted after
neo-tree saves the modified content. Overall, this seems like a lesser
evil compared to Neovim crashing on each rename.

Related to #308

[0]: https://github.com/neovim/neovim/blob/234b8c5f3d57294dda06dbc6c1760e5983bd2c19/runtime/lua/vim/lsp/util.lua#L751-L775
@Gelio
Copy link
Contributor

Gelio commented Nov 6, 2022 •
edited
Loading

FYI I was able to implement this functionality for tsserver. I added the following handler https://github.com/Gelio/ubuntu-dotfiles/blob/d5f693db0e5afd10efacb3269f3a96bf3bade834/install/neovim/stowed/.config/nvim/lua/plugins.lua#L116-L134 for the rename and move neo-tree events https://github.com/Gelio/ubuntu-dotfiles/blob/d5f693db0e5afd10efacb3269f3a96bf3bade834/install/neovim/stowed/.config/nvim/lua/plugins.lua#L176-L183

It may be worth adding this snippet to the documentation or the codebase so others can easily copy/require it and use it themselves.

With this snippet, renaming/moving a file or directory in neo-tree automatically updates import paths in TypeScript.

Keep in mind that the tsserver language server needs to be running in the background for this command to run. This is easy enough, though. Just open any TypeScript file and then your subsequent renames/moves will automatically update imports in other files.

EDIT: I've just noticed I should have posted this in #47 rather than here. My bad

@cseickel
Copy link
Contributor

cseickel commented Nov 6, 2022

FYI I was able to implement this functionality for tsserver.

🤯 You are amazing @Gelio! Thanks for sharing this! I'll link to his comment in the wiki for now.

@Gelio Gelio mentioned this issue Nov 6, 2022
Open
@cseickel cseickel mentioned this issue Nov 25, 2022
Closed
@cseickel cseickel mentioned this issue Jul 19, 2023
Open
1 task
@9mm
Copy link

9mm commented Oct 11, 2023

Is this still an issue? After renaming something I often get this problem after saving, requiring me to hit enter a second time:

@Gelio
Copy link
Contributor

Gelio commented Oct 11, 2023

@9mm I don't experience this. This seems like a candidate for a separate issue if you are sure this happens because of neo-tree.

Did you try disabling neo-tree, renaming, and then saving the file again? Let this be the deciding factor for you whether to create a separate issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@Gelio @9mm @cseickel @nyngwang @gegoune