-
Notifications
You must be signed in to change notification settings - Fork 49
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.
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
bug: line highlights/signs are not applied until leaving insert mode #315
Comments
I'm going to need an example as well as your config, this does not happen for me. There are edge cases depending on when the debounce runs and your typing speed but as is this is far too vague. |
Hm, I'm going to close this for now as it looks like this behavior isn't present with a minimal config. Apologies! |
Okay, not sure if this is or is not a bug on your end of things or on
To replicate the bug, open a file, type insert "# heading" and you will see that the highlights aren't applied until you leave insert mode. If you remove |
I do get the same behavior, thanks for digging into it. Another edge case with lazy loading, wonderful! If you open up another buffer that new buffer will work as expected. Most likely the bug started from this commit: 1ba6fb7, which was done to handle a problem when lazy loading using |
## Details Issue: #315 Previously we added a step to attach to the current buffer to handle `vim-plug` based lazy loading not running for the initial file. This causes a problem with `lazy.nvim` since the attach function will run before picking up user configuration values, which will cause the first buffer to be out of sync from the user configuration. As a sort of hacky but good enough solution run the lazy load handling attach calls behind a vim.schedule. This should result in the event based ones running first and avoid this problem.
Should be fixed by: b9c98ff |
I know you don't want to support lazy loading, and I assume it's intended, but just in case it wouldn't be intentional: this commit impacts lazy loading with |
## Details Related issues: - #309 - #315 - #317 Okay this is getting convoluted to handle the differences in lazy loading between `lazy.nvim` and `vim-plug`. The issues are as follows: - `lazy.nvim` & Lazy Loaded: Attempting to attach to current buffer at the start will not pickup user configuration (called from plugin directory before setup) so may not listen to all needed events. This means we should not attach to current buffer and rely on the `FileType` auto command. - `vim-plug` & Lazy Loaded: The initial load swallows the `FileType` event for the current buffer (`lazy.nvim` seems to trigger the event) so first buffer will be ignored. This means we cannot rely on the `FileType` auto command and need to attach to the current buffer. To fix this we need to be aware of the plugin manager being used so we can do the right thing, which sucks, but oh well. The solution expands on our existing logic to hook into `lazy.nvim` configuration for this plugin. When the user has NOT configured lazy loading (via filetypes nor commands) we attempt to attach to the current buffer. This means if they have we will skip attaching and will rely on the `FileType` event. This solves the `lazy.nvim` problem of not using the updated user configuration. This does mean when not lazy loading with `lazy.nvim` we will attempt to attach to the current buffer. This will initially fail since the filetype will not be set for the buffer but will succeed for the buffer later once the `FileType` event is triggered. For `vim-plug` we don't have any hooks so no matter what it will look like we are NOT lazy loading. This means we will attempt to attach to the current buffer fixing the issue of lazy loading with `vim-plug`. Have also added a check that buffer is valid in the `should_attach` function. The issue related to this should be fixed from the other updates but having it in place seems like a good idea in either case.
Should be fixed by: 4645c18 |
Neovim version (nvim -v)
0.10.4
Neovim distribution
LazyVim
Operating system
MacOS
Terminal emulator / GUI
kitty
Describe the bug
when, for example, adding a new heading, the highlights/border/signs/etc are not applied until insert mode is left, which is new behavior. The same is true for horizontal rules.
The text was updated successfully, but these errors were encountered: