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: The initial fold-level setting doesn't take immediate effect. #539

Closed
3 tasks done
NGPONG opened this issue Jul 11, 2024 · 2 comments
Closed
3 tasks done

bug: The initial fold-level setting doesn't take immediate effect. #539

NGPONG opened this issue Jul 11, 2024 · 2 comments
Labels
bug Something isn't working stale

Comments

@NGPONG
Copy link

NGPONG commented Jul 11, 2024

Did you check docs and existing issues?

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

Neovim version (nvim -v)

lastest

Operating system/version

linux

Describe the bug

I noticed that the code here can set the default fold level.

if self.renderer.foldlevel == nil then
local level = vim.wo[self.win.win].foldlevel
if level < self.renderer.max_depth then
self.renderer:fold_level({ level = level })
-- render again to apply folds
return self:render()
end
end

I tried using this config segment, but it didn't work immediately. In the video below, after successfully opening trouble, the content inside is empty. Moving the cursor to the trouble view doesn't refresh the content instantly. It only refreshes after a certain action (as shown in the video, it refreshes when I move the cursor back to the main buffer; although the cursor doesn't actually go back to the main buffer, which might be a clue).

2024-07-11.194241.mp4

The current default fold-level setting is achieved by extracting an attribute from the window. In my opinion, configuring it this way might not be very user-friendly for the end-user: it means we need to obtain its winid before even opening trouble. I am unsure if this configuration is intended to be open; I might have missed something, so this might not be a bug.

Regards !

Steps To Reproduce

See above

Expected Behavior

See above

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",
  { "folke/trouble.nvim", opts = {} },
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here
@NGPONG NGPONG added the bug Something isn't working label Jul 11, 2024
Copy link
Contributor

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 Aug 11, 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 Aug 19, 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
Development

No branches or pull requests

1 participant