The floating window yet again froze my vim, and I managed to hit ctrl-c to interrupt it. After this, evaluations show this error
And the floating window is now stuck 😂
That's not good, I'm really sorry you've had to deal with that! I've never seen this before, not sure what the ml_get
part is :thinking_face:
It’s probably in a bad state right now. The interesting error might have been the one where I interrupted a stuck neovim (waiting for the floating window to appear, as mentioned before).
But, it turns out that there might be some leak of sorts somehow that grows with usage. A fresh instance of neovim starts off snappy, and then slowly all interactions are getting kind-of slower.
I’m using VimR, not sure if it makes any difference or not.
:thinking_face: I haven't seen it slow down overtime even working in my shared team pairing host (an AWS instance across the Atlantic for me with limited single core performance). I am fairly confident there's some mixture of plugins that's not working well together, but I'm not ruling out my code entirely of course. There definitely could be something wrong.
Knowing that it's a GUI frontend may come in handy since I've never tested Conjure in that sort of environment before. I can't imagine it'd make a difference, but maybe!
It might not handle massive long buffers as well as the TUI versions?
I do wonder if you can reproduce it without the GUI, might be interesting to see if that remains snappy in a terminal throughout the day?
I can see issues like "Frequent crashes when quitting VimR with 30+ buffers opened" on the repo which leans my concern towards VimR a little bit, but not entirely.
https://github.com/qvacua/vimr/issues/782 could also be related since conjure ends up creating a large buffer that is trimmed over time, vimr may be leaking memory in buffers that change a lot (like the conjure log)
Thanks for looking into this. The last issue does seem relevant, yes. Next week I’ll try a terminal session.