bug: invalid 'end_col': out of range' while searching symbols in a perl file

[brneor]

Did you check docs and existing issues?

• [x] I have read all the snacks.nvim docs
• [x] I have updated the plugin to the latest version before submitting this issue
• [x] I have searched the existing issues of snacks.nvim
• [x] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

v0.10.4

Operating system/version

Fedora 41 on WSL (Windows 11)

Describe the bug

Using the picker for searching for symbols (<Leader>ls in AstroNvim) in a Perl file gives me a error: ...nvim/lazy/snacks.nvim/lua/snacks/picker/core/preview.lua:320: Invalid 'end_col': out of range on preview window.

Steps To Reproduce

1. Create a minimal perl file:

sub my_test {
	print "Hello World\n";
}

2. Install perlnavigator
3. <Leader>ls with the perl file open.

Expected Behavior

Preview should work.

Additional Context

I checked the mappings for <Leader>ls on AstroNvim code:

  maps.n["<Leader>ls"] = {
    function()
      local aerial_avail, aerial = pcall(require, "aerial")
      if aerial_avail and aerial.snacks_picker then
        aerial.snacks_picker()
      else
        require("snacks").picker.lsp_symbols()
      end
    end,
    desc = "Search symbols",
  }
end

~Running :lua require("aerial").snacks_picker() triggers the issue, but :lua require("snacks").picker.lsp_symbols() does not.~

I've reported this on AstroNvim's repo and I was told this is either an issue with snacks or perlnavigator itself, so I'm trying here first to hopefully get some help on finding the culprit.

Repro

-- save as repro.lua
-- run with nvim -u repro.lua
-- DO NOT change the paths
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "runtime", "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
  -- stylua: ignore
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", "--branch=stable", lazypath })
end
vim.opt.rtp:prepend(vim.env.LAZY or lazypath)

-- install plugins
local plugins = {
	{ "folke/snacks.nvim", opts = { picker = {} } },
	{
		"neovim/nvim-lspconfig",
		dependencies = {
			{ "williamboman/mason.nvim", opts = {} },
			{
				"williamboman/mason-lspconfig.nvim",
				opts = {
					ensure_installed = { "perlnavigator" },
				},
			},
		},
		opts = {
			servers = {
				perlnavigator = {},
			},
		},
		config = function(_, opts)
			local lspconfig = require("lspconfig")
			for server, config in pairs(opts.servers) do
				config.capabilities = require("blink.cmp").get_lsp_capabilities(config.capabilities)
				lspconfig[server].setup(config)
			end
		end,
	},
	{
		"nvim-treesitter/nvim-treesitter",
		opts = {
			ensure_installed = { "perl" },
		},
		config = function(_, opts)
			require("nvim-treesitter.configs").setup(opts)
		end,
	},
	{
		"saghen/blink.cmp",
		event = "InsertEnter",
		opts = {},
	},

	-- add any other plugins/customizations here
}
require("lazy").setup(plugins, {
	root = root .. "/plugins",
})

-- add anything else here (autocommands, vim.filetype, etc.)

[dpetka2001]

The aerial Snacks picker is a custom one included in the aerial plugin itself. Snacks has its own lsp_symbols picker that's included in this codebase and it works without problems. The aerial picker for Snacks is included in the codebase of aerial plugin. Why are you opening the issue here?

[brneor]

Because looks like the lsp_symbols included in this codebase also didn't work properly with minimal repro steps: https://github.com/AstroNvim/AstroNvim/issues/2805#issuecomment-2824129193

And also

I've reported this on AstroNvim's repo and I was told this is either an issue with snacks or perlnavigator itself, so I'm trying here first to hopefully get some help on finding the culprit.

[dpetka2001]

You changed your original post. You said that it doesn't happen with Snacks picker but only with Aerial snacks_picker. Which is the case? Also in the Astronvim issue, you also say that you can't repro it with Snacks Lsp Symbols picker. So, what is actually true?

[brneor]

Ty for your help, I'm going to check with aerial.

[dpetka2001]

@brneor Please re-open the issue. I was able to repro with the following repro.lua

-- save as repro.lua
-- run with nvim -u repro.lua
-- DO NOT change the paths
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "runtime", "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
  -- stylua: ignore
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", "--branch=stable", lazypath })
end
vim.opt.rtp:prepend(vim.env.LAZY or lazypath)

-- install plugins
local plugins = {
	{ "folke/snacks.nvim", opts = { picker = {} } },
	{
		"neovim/nvim-lspconfig",
		dependencies = {
			{ "williamboman/mason.nvim", opts = {} },
			{
				"williamboman/mason-lspconfig.nvim",
				opts = {
					ensure_installed = { "perlnavigator" },
				},
			},
		},
		opts = {
			servers = {
				perlnavigator = {},
			},
		},
		config = function(_, opts)
			local lspconfig = require("lspconfig")
			for server, config in pairs(opts.servers) do
				config.capabilities = require("blink.cmp").get_lsp_capabilities(config.capabilities)
				lspconfig[server].setup(config)
			end
		end,
	},
	{
		"nvim-treesitter/nvim-treesitter",
		opts = {
			ensure_installed = { "perl" },
		},
		config = function(_, opts)
			require("nvim-treesitter.configs").setup(opts)
		end,
	},
	{
		"saghen/blink.cmp",
		event = "InsertEnter",
		opts = {},
	},

	-- add any other plugins/customizations here
}
require("lazy").setup(plugins, {
	root = root .. "/plugins",
})

-- add anything else here (autocommands, vim.filetype, etc.)

If you would be kind, please change the repro steps in your original post with this one, because your original contains the whole Astronvim distro, which should not actually be used in the repro steps. When creating issues, try to provide a repro with actually only the necessary plugins to repro your issue. A whole distro is not actually considered minimal.

Hopefully when the maintainer is back he will be able to investigate properly.

[brneor]

@dpetka2001 updated the issue description and reopened it. Thank you for your attention and patience :)

[dpetka2001]

It would also be nice if you can confirm the repro yourself as well. Just save the contents into a file repro.lua and then open Neovim with nvim --clean -u repro.lua test.pl and do :lua Snacks.picker.lsp_symbols().

[brneor]

Yes I can. Not sure what I did wrong the first time but with the most recent repro.lua I can see the issue with :lua Snacks.picker.lsp_symbols().

[github-actions[bot]]

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.

[dpetka2001]

No stale

[github-actions[bot]]

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.

[brneor]

The issue is still present.

[github-actions[bot]]

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.

[brneor]

issue is still present

[github-actions[bot]]

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[bot]]

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

[brneor]

issue is still present

[dpetka2001]

Open a new one if you'd like because this is closed (or reopen this one I don't know if you have permissions though). You should have commented when you saw the notification from the stale bot, so that it would remain open.

[folke]

re-opened :)

[github-actions[bot]]

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.

[brneor]

issue still present