bug: Cursor shape modified

[mizlan]

Did you check docs and existing issues?

• I have read all the lazy.nvim docs
• I have searched the existing issues of lazy.nvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.9.0 release

Operating system/version

macOS Monterey 12.6.1

Describe the bug

When Lazy detects a new plugin to install and shows the popup on VimEnter, there is a problem where it sets my cursor to a block cursor when it always otherwise is an underline cursor. guicursor is being set in my configuration, and that line is being run because I can check :verbose set guicursor? except now it's a block. The cursor gets reset to an underline when Neovim is exited. I use Kitty terminal emulator.

Steps To Reproduce

1. Set cursor to underline (in Kitty terminal emulator cursor_shape underline
2. Add a new plugin to Lazy config (copy-pasting repro.lua below as it is reproduces the issue for me)
3. Reopen Neovim and wait for Lazy to finish installing new plugin
4. Notice that cursor shape is now a block

Expected Behavior

Cursor shape is still underline

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here

[folke]

Your terminal cursor is unrelated to the guicursor option in Neovim (or at least should be).

What is your guicursor config?

[mizlan]

vim.opt.guicursor = ''

[folke]

lazy doesn't change any cursor settings. I really have no idea why this happens.

Might be a Neovim issue. Won't further look into this. Closing as won't fix.

[isaif]

vim.opt.guicursor = ''

use this instead:
vim.opt.guicursor = 'a:block'

[mizlan]

Ooh I think this works, but it is weird that I need it...

[mizlan]

@folke I think it is actually many more problems, where basically the code in my Neovim config is either overwritten (potentially by a plugin that got lazy-loaded after my configuration?) or never applied. These include:

• foldlevel
• signcolumn setting
• laststatus setting
• and aforementioned cursor shape

Assuming it is plugins overwriting these settings (somehow), what would the correct way to fix this be?

[folke]

It turns out that vim.wo[win] sets window global options. Which makes no sense imo.

So I've just updated all usage of vim.wo in lazy to use vim.api.nvim_win_set_option instead.

Unfortnately that probably won't fix your issue, since I'm pretty sure it's other plugins that accidentally change the global options.

[folke]

vim.wo should basically never be used, since that doesn't do what people think it does.

Using vim.opt_local or the api function is what plugins should use.

Very unfortunate that vim.wo works the way it does.

[ibhagwan]

vim.wo should basically never be used, since that doesn't do what people think it does.

Using vim.opt_local or the api function is what plugins should use.

Very unfortunate that vim.wo works the way it does.

@folke, I don't think this is intended behavior, it sounds like a bug, mind me asking how did you reproduce this and got to the conclusion vim.wo changes the option globally?

Fearing this might affect my plugin too I just did a simple test, opened a file in neovim and used :split, then removed number and relative number specifically for the first window using:

:lua vim.wo[1000].number=false
:lua vim.wo[1000].relativenumber=false

This works as expected, only the first window has the numbers removed, works the same if I use the second window index (1003), it also works as expected turning numbers off just for the current window using the short form:

:lua vim.wo.number=false
:lua vim.wo.relativenumber=false

It is worth noting that using an additional :split does "inherit" the current window options but that also happens when using vim.api.nvim_win_set_option and I couldn't find any other difference between using vim.api.nvim_win_set_option vs vim.wo.

Could this be related to something else?

[folke]

It's that second case I was referring to. You can prevent inheritance by using a window local scope. Vim.wo is window global

[folke]

To be clear, it doesn't set the option globally. It sets the option window-global, which is something else

[kuator]

vim.wo should basically never be used, since that doesn't do what people think it does.
Using vim.opt_local or the api function is what plugins should use.
Very unfortunate that vim.wo works the way it does.

@folke, I don't think this is intended behavior, it sounds like a bug, mind me asking how did you reproduce this and got to the conclusion vim.wo changes the option globally?

Fearing this might affect my plugin too I just did a simple test, opened a file in neovim and used :split, then removed number and relative number specifically for the first window using:

:lua vim.wo[1000].number=false
:lua vim.wo[1000].relativenumber=false

This works as expected, only the first window has the numbers removed, works the same if I use the second window index (1003), it also works as expected turning numbers off just for the current window using the short form:

:lua vim.wo.number=false
:lua vim.wo.relativenumber=false

It is worth noting that using an additional :split does "inherit" the current window options but that also happens when using vim.api.nvim_win_set_option and I couldn't find any other difference between using vim.api.nvim_win_set_option vs vim.wo.

Could this be related to something else?

neovim/neovim#14595

[aarondill]

It turns out that vim.wo[win] sets window global options. Which makes no sense imo.

So I've just updated all usage of vim.wo in lazy to use vim.api.nvim_win_set_option instead.

Unfortnately that probably won't fix your issue, since I'm pretty sure it's other plugins that accidentally change the global options.

@folke, I'm not certain which version it was added in, but it's worth noting that my neovim (NVIM v0.10.0-dev, it's the nightly branch) has this to say about nvim_win_set_option():

Deprecated features

API
....
- *nvim_win_set_option()*	Use |nvim_set_option_value()| instead.

Though, the NVIM v0.6.1 help says this and has no mention anywhere about nvim_set_option_value():

nvim_win_set_option({window}, {name}, {value})         *nvim_win_set_option()*
                Sets a window option value. Passing 'nil' as value deletes the
                option(only works if there's a global fallback)

                Parameters: ~
                    {window}  Window handle, or 0 for current window
                    {name}    Option name
                    {value}   Option value

It should be considered when the nvim_win_set_option() function is depreciated (not certain which version), and perhaps plans should be put in place in the future to migrate.