bug: calling tweak_lsp_kind removes icons in statusline of trouble.nvim

[231tr0n]

Did you check docs and existing issues?

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

Neovim version (nvim -v)

NVIM v0.11.0-dev-632+g33464189b

Operating system/version

Ubuntu 24.04 WSL

Describe the bug

Enabling MiniIcons.tweak_lsp_kind() removes icons from statusline component. This also makes document symbols not open and throws error like the one in below picture.

Steps To Reproduce

1. With the repro config, open the same repro config file, you can see that statusline component shown in winbar does not have icons.
2. Comment out MiniIcons.tweak_lsp_kind(). Then do the same thing again. You can see that icons are shown in statusline component in winbar.

Expected Behavior

Icons be shown with statusline component enabled.

Repro

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()
require("lazy.minit").repro({
        spec = {
                "echasnovski/mini.icons",
                "echasnovski/mini.completion",
                "neovim/nvim-lspconfig",
                "folke/trouble.nvim",
        },
})

require("mini.icons").setup()
require("mini.completion").setup()
MiniIcons.mock_nvim_web_devicons()
MiniIcons.tweak_lsp_kind()
require("trouble").setup()
Symbols = require("trouble").statusline({
        mode = "lsp_document_symbols",
        groups = {},
        title = false,
        filter = { range = true },
        format = "> {kind_icon}{symbol.name:Normal}",
        hl_group = "WinBar",
})
vim.api.nvim_create_autocmd("LspAttach", {
        callback = function()
                vim.diagnostic.config({
                        virtual_text = true,
                        underline = false,
                })
                vim.wo.winbar = "  %{%v:lua.Symbols.get()%}"
                vim.lsp.inlay_hint.enable(not vim.lsp.inlay_hint.is_enabled())
        end,
})
local lspconfig = require("lspconfig")
lspconfig.lua_ls.setup({
        settings = {
                Lua = {
                        hint = {
                                enable = true,
                        },
                        runtime = {
                                version = "LuaJIT",
                        },
                        completion = {
                                callSnippet = "Replace",
                        },
                        workspace = {
                                checkThirdParty = false,
                                library = {
                                        vim.env.VIMRUNTIME,
                                },
                        },
                },
        },
})

[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.

[231tr0n]

This is relavant!!! Please dont mark it 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.

[folke]

For every document symbol, Trouble maps its numeric id to the associated name (like 13 -> Variable). Those names are then used to both filter which symbols should be shown and to map to a certain icon.

tweak_lsp_kind effectively changes the associated names, so that will indeed break Trouble (and also things like Noice's lsp integrations I believe).

For Trouble I could use a fixed mapping instead of relying on vim.lsp.protocol.SymbolKind, but that seems a bit backward.

@echasnovski what do you think?

[folke]

I just kinda fixed this, but this shouldn't be needed imo. I don't like it :)

[echasnovski]

Tweaking num -> string part of vim.lsp.protocol.SymbolKind (and vim.lsp.protocol.CompletionItemKind) seems like a one-stop-shop way to enable icons in all places that use them. My reasoning was (and still is) that this part of protocol is usually used in the latest stages just to display kind to the user. Before that it can be stored as number id.

The string -> num part is intentionally left untouched to preserve initial data for plugins that want to use LSP's original names.

I just kinda fixed this, but this shouldn't be needed imo. I don't like it :)

That's something I do in 'mini.extra' and seems relatively ok.

[folke]

Makes sense. Thank you for the additional context!