startup.nvim
startup.nvim copied to clipboard
Cursor position outside buffer.
Describe the bug Startup won't launch due to cursor position being placed outside buffer.
Checklist
- [x] Checked if issue already exists
- [x] I'm using the latest startup.nvim version
To Reproduce Steps to reproduce the behavior:
- Add
startup.nvim
toplugins.lua
by coping the contents of the first source-block in the installation section of theREADME.md
. -
:PackerSync
. - w/o dashboard config provided in this repo, the same error will arise.
Expected behavior
The launch of startup.nvim
w/o the provided configuration file.
Logs
Error executing vim.schedule lua callback: ...m/site/pack/packer/opt/startup.nvim/lua/startup/init.
lua:524: Cursor position outside buffer
stack traceback:
[C]: in function 'nvim_win_set_cursor'
...m/site/pack/packer/opt/startup.nvim/lua/startup/init.lua:524: in function 'fn'
vim.lua:415: in function 'cb'
vim.lua:285: in function <vim.lua:285>
Additional Info Config dashboard.lua
Neovim Version NVIM v0.6.1
Same here.
I have no problem when I use your config does it happen every time or just sometimes?
For me its every time.
Likewise and it does occur both when I use a config and when I refrain from using one.
I had this problem if the auto-session plugin has the auto restore option enabled One idea would be to check if this option is enabled, disable startup.nvim to avoid problems, or else display a warning that keeps both options active at the same time can cause problems Yes, the README has this information, but I think a built-in option would be interesting
This function does this check I mentioned:
function verify_auto_restore()
if package.loaded['startup'] then
if (package.loaded['auto-session'].conf.auto_restore_enabled == true) then
vim.api.nvim_echo({{'WARNING: The auto_restore_enabled option of the auto-session plugin can cause startup problems in startup.nvim', 'ErrorMsg' }}, false, {})
end
end
end
I wont
I had this problem if the auto-session plugin has the auto restore option enabled One idea would be to check if this option is enabled, disable startup.nvim to avoid problems, or else display a warning that keeps both options active at the same time can cause problems Yes, the README has this information, but I think a built-in option would be interesting
This function does this check I mentioned:
function verify_auto_restore() if package.loaded['startup'] then if (package.loaded['auto-session'].conf.auto_restore_enabled == true) then vim.api.nvim_echo({{'WARNING: The auto_restore_enabled option of the auto-session plugin can cause startup problems in startup.nvim', 'ErrorMsg' }}, false, {}) end end end
I won't do that Because there are just so many auto sessions. You could do this yourself or use the options specified in the readme: https://github.com/startup-nvim/startup.nvim#conflicts-with-other-plugins-like-auto-session
@Icy-Thought @HrvojeFER do you also use auto session plugins?
Yes.
I don't. It could be something else for me though if @Icy-Thought confirms that auto-session is the source of the problem.
EDIT: sry for the late reply and im @HrvojeFER - this is just a different account
Was playing around with this.
If I pass an empty table to the startup (startup({})
, it shows the error.
I copied the default "dashboard" config into my startup config directly and it starts fine. Then I:
- Commented out the options and mapping section - Started fine
- Started with just the header section - fine
- Started with just the body section - fine
- Started with just the footer section - gave the error, but still showed the footer
I think I figured it out? If I have a section that only has one line of content, it errors (like the default footer section), but if I add two blank lines, it works fine:
require("startup").setup({
header = {
type = "text",
oldfiles_directory = false,
align = "center",
fold_section = false,
title = "Something",
margin = 1,
content = {
"",
"", -- If I delete this, I get the error.
},
highlight = "Normal",
default_color = "",
oldfiles_amount = 0,
},
parts = {"header"},
})
The error also occurs if you don't provide any sections in the user config. That should probably be caught ahead of time with a warning so people know why startup didn't do anything.
i can confirm the issue appears to be empty {}
being passed to setup
. I checked and it appears to be due to the default settings that get merged with the the argument to setup
if it exists - this commit makes Startup not break for me.