Skip to content
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: Switching buffers while in ZenMode doesn't apply ZenMode options #95

Closed
3 tasks done
Subjective opened this issue Jul 14, 2023 · 2 comments · May be fixed by #99
Closed
3 tasks done

bug: Switching buffers while in ZenMode doesn't apply ZenMode options #95

Subjective opened this issue Jul 14, 2023 · 2 comments · May be fixed by #99
Labels
bug Something isn't working stale

Comments

@Subjective
Copy link

Subjective commented Jul 14, 2023

Did you check docs and existing issues?

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

Neovim version (nvim -v)

NVIM v0.10.0-dev-664+g0ce391086

Operating system/version

MacOS 13.4

Describe the bug

Switching buffers while in ZenMode doesn't apply zen-mode options.

There is also this strange issue where ZenMode does apply zen-mode options when switching to certain buffers, but the original options for those buffers are not restored upon exiting ZenMode, though I haven't been able to trace the root cause as it is rather inconsistent. (I think it may be lsp-related, as it only happens on buffers that lsps like lua_ls and tsserver attach to, but I'm not entirely sure).

As you can see from the example, ZenMode options are applied to all buffers except the one with 2.lua opened, which is the only one that has its original line number column restored upon exiting ZenMode.
Screen Recording 2023-07-14 at 3 52 51 PM

Steps To Reproduce

  1. Toggle ZenMode
  2. Open new buffers
  3. ZenMode options are not applied to new buffers

Expected Behavior

I would expect that ZenMode options are applied when switching between buffers while ZenMode is enabled, and that the original buffer options (signcolumn, line numbers, etc.) are properly restored disabling ZenMode.

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)

vim.keymap.set("n", "H", "<cmd>bprev<cr>")
vim.keymap.set("n", "L", "<cmd>bnext<cr>")

vim.opt.number = true
vim.opt.relativenumber = true
vim.opt.foldcolumn = "2"
vim.opt.signcolumn = "yes"

-- install plugins
local plugins = {
	"folke/tokyonight.nvim",
	{
		"folke/zen-mode.nvim",
		cmd = "ZenMode",
		opts = {
			window = {
				backdrop = 1,
				width = function()
					return math.min(120, vim.o.columns * 0.75)
				end,
				height = 0.9,
				options = {
					number = false,
					relativenumber = false,
					foldcolumn = "0",
					list = false,
					showbreak = "NONE",
					signcolumn = "no",
				},
			},
			plugins = {
				options = {
					cmdheight = 1,
					laststatus = 0,
				},
			},
		},
	},
	-- add any other plugins here
}
require("lazy").setup(plugins, {
	root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here
@Subjective Subjective added the bug Something isn't working label Jul 14, 2023
@Subjective Subjective changed the title bug: Switching buffers while in ZenMode doesn't apply zen-mode options bug: Switching buffers while in ZenMode doesn't apply ZenMode options Jul 14, 2023
Copy link
Contributor

github-actions bot commented Jul 6, 2024

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

@github-actions github-actions bot added the stale label Jul 6, 2024
Copy link
Contributor

This issue was closed because it has been stalled for 7 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working stale
Projects
None yet
1 participant