Closed j-xella closed 11 months ago
Not enough information. You haven't even provided the debug messages.
Not enough information. You haven't even provided the debug messages.
Yes, I did not provide debug messages. This issue does not happen consistently, and I normally do not run it with debug enabled...
I understand that this issue is very difficult to reproduce. But my quesion also was if there is a workaround possible to restore the gitsigns behaviour without restarting neovim? Clearly some internal gitsigns data becomes wrong. I wonder if providing the error message should at least give a clue where it happens, and maybe something can be done to fix inside neovim session it so that the work could continue?
I would expect closing and opening the buffer again to fix the issue. Perhaps Gitsigns isn't cleaning up the state properly.
Any fix?
To recreate this bug detach
on InsertEnter
and attach
on InsertLeave
over the course of an editing session.
This often happens because I dynamically attach
and detach
Gitsigns
when entering and leaving Insert
mode.
In Insert
mode I like to turn off colors, highlights, and other visual distractions. I enable them back on in Normal
mode.
Unfortunately, restarting Nvim
is the only way I've found to resolve this issue.
I think the problem could be in throttle_by_id
function. It creates a function wrapper that ensures that the function does not get invoked multiple times in parallel for any particular buffer. One of the ways to do it is via local running[id]
map, where id
is the buffer number. While the function is being executed, running[id] is true, and that ensures that the function will not be called again for that buffer. Once the function is finished, running[id] is set to nil/false, and the function can be called again.
The problem is that if an exception is raised while the function was running, running[id] is never reset, and the function for that buffer can't be called any more. I believe the wrapper should use pcall
or xpcall
to call the function, and ensure that running[id] is reset no matter what.
A workaround is to use bwipeout
on the buffer. bdelete does not delete the buffer completely. When the buffer is loaded again, it retains the buffer id and hence gitsigns still doesn't work on it. bwipeout, on the other hand, does much better purge, and when the buffer is loaded again, it gets new buffer id assigned. Hence it is possible to make gitsigns work on it without restarting nvim. The drawback is that bwipeout deletes all buffer bookmarks and other buffer-specific settings.
Good find.
The problem is that the function being wrapped is async so pcall won't necessarily work.
I hope it is still possible to ensure that running[id]
is reset at the end...
But if not, maybe it is possible to move the running
map to the unit level and expose another function that could reset running[id]
- to use in cases of emergency? Still better than bwipeout.
Another solution could be to use timeouts - store the timestamp of the last invocation, and, if the function is "running" for longer than certain amount of time, assume that it is not anymore and proceed.
Knowing the issue is coming from running[id]
is valuable so I'm sure something can be figured out.
It may just be the case to make sure the async framework can properly handle pcall which is on my to-do list anyway.
I am not sure if this is the same issue or a slightly different one, but I am noticing much more cases where gitsigns stops working on a buffer. Like before, it does not happen every time, but multiple times a day. bwipeout
helps, so it could be this issue. However, there are no visible error messages, only at some point I notice that gitsigns just does not work on a buffer any more.
Assuming that you have this keybinding:
map.set('v', '<leader>gs', function() gs.stage_hunk {vim.fn.line('.'), vim.fn.line('v')} end)
qq<shift-v>gsn
30@q
I think It has to do with the speed or something too, it can't handle too many calls too fast, you can also test the issue by hammering the @@
afterwords and you will have the same effect
That stacktrace is from a version of gitsigns from at least 5 months a go. Please re-run on the latest.
This should be fixed by #925
Description
Something happens to a buffer, and gitsigns is unable to work with it any more. Other buffers are ok, but not this particular one. There could be several such buffers at a time.
Closing the window or even deleting the buffer with
:bdel
doesn't help - after the buffer is reopened, the problems continue.If the fix is not awailable, I would like to be able to resolve this issue without restarting neovim at least - I have so many buffers and terminal windows open. Is it possible to restart/reset gitsigns without reopening neovim?
Neovim version
NVIM v0.9.0-dev-650+g870ca1de5 Build type: Release LuaJIT 2.1.0-beta3
Operating system and version
Red Hat Enterprise Linux Server 7.9 (Maipo)
Expected behavior
Gitsigns works as usual with a buffer. Displays hints in a gutter, jumps between hunks, etc...
Actual behavior
Nothing is displayed in a gutter.
When I try jumping between diffs, I get this:
Minimal config
Steps to reproduce
Not sure. This happens rarely and inconsistently.
My guess would be that background git operations could be responsible somehow. I think the problems started when I did some command-line rebasing of the code opened in neovim buffers.
Gitsigns debug messages
No response