Wrap auto load in vim.schedule #12
Conversation
I'm experiencing a bug whereby if I enable autoloading, I don't get any syntax highlighting on startup (until I trigger it with `:e` for example). I had the same issue with `persistence.nvim` (I made an auto command to get the same functionality). For both plugins, wrapping the call to `load` in `vim.schedule` solved the problem. I don't really know enough about the inner workings of Neovim to explain this though.
|
This may also help solve #11 as well! |
|
Many thanks @simonmclean |
|
@simonmclean...I've noticed that vim.schedule is causing issues with tests and generally seems to be slow at loading the session file. I'm going to work on a solution which uses |
|
Ah, okay. I guess it isn't surprising that it's messed with the tests, as it makes a previously synchronous function asynchronous. My impression though is that the autoload feature will always run into this bug if |
A big shoutout to @simonmclean for this pull request. Previously we autoloaded a session file as soon as Neovim opened. The problem with this is that key plugins like LSP and Treesitter may not have been initialised. This would lead to syntax highlighting issues or LSPs not attaching to buffers in the session. Pushing this to Neovim's event loop via vim.schedule allows us to sensibly load the session after these key plugins. Fixing the tests was a little cumbersome as we needed to use plenary's async library but once figured out, we have some lovely robust async tests
|
I figured out how to write some async tests so this should be solved now and we should load and start sessions using |
|
|
I'm experiencing a bug whereby if I enable autoloading, I don't get any syntax highlighting on startup (until I trigger it with
:efor example). I had the same issue withpersistence.nvim(I made an auto command to get the same functionality). For both plugins, wrapping the call toload()invim.schedulesolved the problem.I don't really know enough about the inner workings of Neovim to explain this though.