~whynothugo/lsp_lines.nvim#40: 
add option to exclude certain filetypes

In certain buffers (for example in Lazy.nvim https://imgur.com/a/SfUhhb8) it displays lsp_lines.

I don't know if it is a bug related to the extmarks, but I think a simple fix would be to just disable the plugin on certain filetypes.

I am new to sourcehut if I can I will try to make a pr (maybe they are called patches on here, I will look into it)

Thanks for the awesome plugin

Status
REPORTED
Submitter
~lnk3
Assigned to
No-one
Submitted
10 months ago
Updated
10 months ago
Labels
No labels applied.

~whynothugo 10 months ago

For the general case, you probably want to disable the default virtual_text for diagnostics to avoid the duplication. This is mentioned in the readme: https://sr.ht/~whynothugo/lsp_lines.nvim/#setup

For this particular case, it looks like virtual_textmight actually be more convenient, so you can also disable this plugin on a per-filetype basis (probably with an auto-command, see :h autocmd).

The diagnostics text rendered by this plugin look misaligned. My guess is that Lazy.nvim is setting diagnostics at column 0, instead of the column where the plugin is actually defined, that is why the "lines" point to the wrong column. You might want to report this to Lazy.nvim.

I am new to sourcehut if I can I will try to make a pr (maybe they are called patches on here, I will look into it)

Patches are a git thing. PRs are github's reinvention of how patches are shared. The main difference is that the patch is send out via email (usually to a list). You can do this with git-send-email or with sourcehut's web-ui for that. If you're interested, looking at the docs for git-send-email and https://git-send-email.io/ are a good start.

However, for this case, I suggest you try to set up an autocommand in your config that simply disables this plugin for this filetype. It's probably an easier start and honestly sounds like a better place to address this kind of situation.

~lnk3 10 months ago

Hi, I appreciate your quick response!

I considered registering a simple autocmd to exclude Lazy.nvim, but I thought it might be beneficial for others if the plugin could handle it internally.

I will maybe file an issue or pr to Lazy.nvim about the misalignment.

I wasn't aware of git patches before (although I vaguely remember hearing about them, it rings a bell in my memory), thank you for taking the time to introduce me to them, pretty cool!

PS: I followed the readme and the duplication doesn't bother me in other buffers :) I have a keymap to quickly toggle it if it becomes too polluting and autocmds to disable it in insert mode, I like this plugin a lot it makes diagnostics very clear to read

~lnk3 10 months ago*

Maybe this issue could be useful to someone else. Here is my Lazy.nvim spec for this plugin, I solved the problem in Lazy like the author suggested: by using a FileType autocmd

-- Disable the plugin in Lazy.nvim
vim.api.nvim_create_autocmd("FileType", {
    pattern = "lazy",
    callback = function()
        local previous = not require("lsp_lines").toggle()
        if not previous then require("lsp_lines").toggle() end
    end
})

return {
    "https://git.sr.ht/~whynothugo/lsp_lines.nvim",
    event = "LspAttach",
    config = function()
        require("lsp_lines").setup()

        require("lsp_lines").toggle() -- Comment to disable on startup
        local previously = not require("lsp_lines").toggle()

        local group = vim.api.nvim_create_augroup("LspLinesToggleInsert", { clear = false })
        vim.api.nvim_create_autocmd("InsertEnter", {
            group = group,
            callback = function()
                previously = not require("lsp_lines").toggle()
                if not previously then
                    require("lsp_lines").toggle()
                end
            end,
        })

        vim.api.nvim_create_autocmd("InsertLeave", {
            group = group,
            callback = function()
                if require("lsp_lines").toggle() ~= previously then
                    require("lsp_lines").toggle()
                end
            end,
        })
    end,
}
Register here or Log in to comment, or comment via email.