-
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: Invalid buffer id #317
Comments
I am also getting this, but I do NOT get it every time. (Like opening a clean session). My first theory was that it conflicted with auto-sessions. But the following vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()
require("lazy.minit").repro({
spec = {
{
'MeanderingProgrammer/render-markdown.nvim',
dependencies = { 'nvim-treesitter/nvim-treesitter', 'nvim-tree/nvim-web-devicons' }, -- if you prefer nvim-web-devicons
---@module 'render-markdown'
---@type render.md.UserConfig
opts = {},
},
{
'rmagatti/auto-session',
lazy = false,
---enables autocomplete for opts
---@module "auto-session"
---@type AutoSession.Config
opts = {
suppressed_dirs = { '~/', '~/Projects', '~/Downloads', '/' },
-- log_level = 'debug',
}
},
},
}) Any ideas? |
what i have found, if i give some delay before opening old session it will not show the error. for now i use lazy.nvim and use the previous tag of v7.7.0 |
getting this issue too when it loads a session |
## 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.
Thanks for the report, should be resolved by: 4645c18. |
Neovim version (nvim -v)
0.10.4
Neovim distribution
n/a
Operating system
macOS
Terminal emulator / GUI
Ghostty
Describe the bug
After the last commit, I'm getting an error when the plugin loads:
Expected behavior
There should be no error
Healthcheck output
Plugin configuration
Plugin error log
Confirmations
Additional information
No response
The text was updated successfully, but these errors were encountered: