context.vim
context.vim copied to clipboard
Disable in preview window
IMHO there seems to be no reason to have this plugin enabled in the preview window, but there is currently no way to deactivate it there, as far as I can see.
@ThomasFeher: Yes, it shouldn't be active in the preview window. There's already a check in context#update() which should abort if 'previewwindow' is set. Could you show a screenshot of where you see a context of a preview window? And maybe give steps to reproduce? Thanks!
It always happens when the floating window created by context.vim is active and subsequently a preview window is opened. The floating window in the preview window shows the same content as the one in the main window.
I'm on neovim v0.4.3, using the default options for contex.vim.
Thanks, I understand what you mean now. I believe what's happening is a bit different though:
- You have a buffer open and a context popup visible at the top of it.
- In insert mode you trigger a preview window. This pushes down the buffer to make space for the preview window.
- At this time context.vim doesn't do anything. The context popup from above is still in the old position where it at least partially obstructs the preview window.
- Once you leave insert mode context.vim gets activated again (by the CursorMoved auto command). At this time the context popup should be moved down to be at the top of the buffer again. This should fully clear the preview window again.
@ThomasFeher: Can you confirm that this description matches your observations?
If so I might need to hook into some insert mode autocommands (CursorHoldI CursorMovedI TextChangedI) so context.vim gets a chance to recognize that a preview window has been opened to move the context popup accordingly.
No.
- Open a buffer and navigate so that the context popup is visible.
- Open preview window (using
:pta …for example) in normal mode. - Both windows now do contain a popup window with the same content. The popup window of the preview window does neither change its content nor its position while navigating the preview window.
setting g:context.logfile right after step 1 results in the following log after step 2:
> context+update CursorMoved
> context+popup+update_context 2
> open
> context+popup+nvim+open
> context+popup+redraw 2
> context+popup+nvim+redraw 2
> context+popup+layout
> context+popup+redraw 2
> context+popup+nvim+redraw 2
> context+popup+redraw 2
> context+popup+nvim+redraw 2
> context+popup+redraw no force skip top
> context+update CursorMoved
> context+popup+update_context 2
> context+popup+redraw 2
> context+popup+nvim+redraw 2
> context+popup+layout
> context+popup+redraw 2
> context+popup+nvim+redraw 2
> context+popup+redraw 2
> context+popup+nvim+redraw 2
Just reproduced with all plugins deactivated despite of vim-plug and context.vim.
Thank you, I'll try to reproduce that later 👍
Edit: Managed to reproduce 👍
Quick update: I believe this is similar to the issue #36. I just opened a Neovim issue about it: https://github.com/neovim/neovim/issues/11878
So the problem here seems to be: When the preview window gets opened it appears to context.vim (as triggered from the CursorMoved autocommand) as the old (non preview) buffer, so context.vim calculates the context (which is the same as before) and displays it on top of the new window. Only after that's done the buffer which belongs to the new window appears to be changed to the preview buffer, and for that one context.vim does nothing. And that includes that we don't check if that buffer/window has a context popup, so it never gets cleaned up. (because it's not expected for a preview buffer to have a context popup in the first place)
I'll see if I can find a tolerable workaround for now.
https://github.com/neovim/neovim/issues/11878 has been closed now, so the code can probably be simplified? (workaround removed)