jose-elias-alvarez / null-ls.nvim

Use Neovim as a language server to inject LSP diagnostics, code actions, and more via Lua.
Other
3.64k stars 789 forks source link

null_ls.builtins.diagnostics.todo_comments breaks tsx treesitter syntax highlighting in new buffers #1527

Open thallada opened 1 year ago

thallada commented 1 year ago

FAQ

Issues

Neovim Version

v0.9.0

Dev Version?

Operating System

MacOS (but also reproducible on WSL Linux)

Minimal Config

-- this template is borrowed from nvim-lspconfig
local on_windows = vim.loop.os_uname().version:match("Windows")

local function join_paths(...)
    local path_sep = on_windows and "\\" or "/"
    local result = table.concat({ ... }, path_sep)
    return result
end

vim.g.loaded_remote_plugins = ""
vim.cmd([[set runtimepath=$VIMRUNTIME]])

local temp_dir = vim.loop.os_getenv("TEMP") or "/tmp"

vim.cmd("set packpath=" .. join_paths(temp_dir, "nvim", "site"))

local package_root = join_paths(temp_dir, "nvim", "site", "pack")
local install_path = join_paths(package_root, "packer", "start", "packer.nvim")
local compile_path = join_paths(install_path, "plugin", "packer_compiled.lua")

local null_ls_config = function()
    local null_ls = require("null-ls")
    -- add only what you need to reproduce your issue
    null_ls.setup({
        sources = {
            null_ls.builtins.diagnostics.todo_comments,
        },
    })
end

local function load_plugins()
    -- only add other plugins if they are necessary to reproduce the issue
    require("packer").startup({
        {
            "wbthomason/packer.nvim",
            {
                'nvim-treesitter/nvim-treesitter',
                run = function() require('nvim-treesitter.install').update({ with_sync = true }) end,
                config = function()
                    require('nvim-treesitter.configs').setup {
                        ensure_installed = { "typescript", "tsx" },
                        auto_install = true,
                        highlight = {
                            enable = true,
                        }
                    }
                end,
            },
            {
                "jose-elias-alvarez/null-ls.nvim",
                requires = { "nvim-lua/plenary.nvim" },
                config = null_ls_config,
            },
            {
                'ellisonleao/gruvbox.nvim',
                config = function()
                    require('gruvbox').setup()
                    vim.o.background = "dark"
                    vim.api.nvim_command([[colorscheme gruvbox]])
                end,
            }
        },
        config = {
            package_root = package_root,
            compile_path = compile_path,
        },
    })
end

if vim.fn.isdirectory(install_path) == 0 then
    vim.fn.system({ "git", "clone", "https://github.com/wbthomason/packer.nvim", install_path })
    load_plugins()
    require("packer").sync()
else
    load_plugins()
    require("packer").sync()
end

Steps to Reproduce

  1. nvim --clean -u minimal_init.lua
  2. :e sample1.tsx
    
    import React from "react";

const Sample1 = () => { const sample1 = "sample1"; return (

{sample1}

); };

3. `:vsplit sample2.tsx`
```tsx
import React from "react";

const Sample2 = () => {
  const sample2 = "sample2";
  return (
    <div>
      <p>{sample2}</p>
    </div>
  );
};
  1. Window should look like screenshot below. sample2.tsx on the left has broken syntax highlighting while sample1.tsx on the right has the correct syntax highlighting (notice colors of import, const, and jsx tags). nullls_bug

Reproducibility Check

Expected Behavior

I expect all typescriptreact buffers I open to have consistent syntax highlighting from the tsx treesitter plugin.

Actual Behavior

Only new typescriptreact buffers I open after the first initial typescriptreact buffer have incorrect syntax highlighting.

Removing the null_ls.builtins.diagnostics.todo_comments source from the nullls config fixes the issue.

Debug Log

Dates are not recent, so I think these errors are not related:

[WARN  Fri Oct 14 18:28:14 2022] ...ack/packer/start/null-ls.nvim/lua/null-ls/generators.lua:92: failed to run generator: ...site/pack/packer/start/null-ls.nvim/lua/null-ls/loop.lua:165: command codespell is not executable (make sure it's installed and on your $PATH)
[WARN  Fri Oct 14 21:33:39 2022] ...ack/packer/start/null-ls.nvim/lua/null-ls/generators.lua:92: failed to run generator: ....nvim/lua/null-ls/builtins/diagnostics/todo_comments.lua:98: attempt to index a nil value
[WARN  Fri Nov 11 15:25:13 2022] ...ack/packer/start/null-ls.nvim/lua/null-ls/generators.lua:92: failed to run generator: ....nvim/lua/null-ls/builtins/diagnostics/todo_comments.lua:98: attempt to index a nil value
[WARN  Sun Nov 20 17:52:34 2022] ...ack/packer/start/null-ls.nvim/lua/null-ls/generators.lua:92: failed to run generator: ....nvim/lua/null-ls/builtins/diagnostics/todo_comments.lua:98: attempt to index a nil value
[WARN  Sat Dec 10 16:32:30 2022] ...ack/packer/start/null-ls.nvim/lua/null-ls/generators.lua:92: failed to run generator: ....nvim/lua/null-ls/builtins/diagnostics/todo_comments.lua:98: attempt to index a nil value
[WARN  Mon Dec 12 23:25:54 2022] ...ack/packer/start/null-ls.nvim/lua/null-ls/generators.lua:94: failed to run generator: ....nvim/lua/null-ls/builtins/diagnostics/todo_comments.lua:98: attempt to index a nil value
[WARN  Tue Jan 31 00:23:48 2023] ...ack/packer/start/null-ls.nvim/lua/null-ls/generators.lua:94: failed to run generator: ....nvim/lua/null-ls/builtins/diagnostics/todo_comments.lua:98: attempt to index a nil value

Help

Yes, but I don't know how to start. I would need guidance

Implementation Help

It took me a long time to narrow down the issue to null-ls and then todo_comments. It would be great if null-ls echoed a more obvious error if there is an error in one of the plugins that causes syntax to break (I still have not found any error message that would point to what about todo_comments is breaking this).

Requirements

jose-elias-alvarez commented 1 year ago

So after looking into this a bit, it looks like this line is causing issues. We are passing typescriptreact as the 2nd argument, but we need to use tsx instead. It looks like Neovim maintains a correspondence table, so we should use that instead if it's not specifically marked internal.

However, I also think something is broken upstream. as the following steps can also reproduce your issue independent of null-ls:

  1. nvim --clean -u minimal_init.lua
  2. :e sample1.tsx
  3. :lua vim.treesitter.get_parser(0, "typescriptreact")
  4. :vsplit sample2.tsx

It looks like just calling get_parser() with a nonexistent language breaks Treesitter for subsequent buffers, even when using pcall (which is what the todo_comments source does). It might be worth reporting if you're up for it.

thallada commented 1 year ago

Thanks for the investigation, I opened an issue here: https://github.com/nvim-treesitter/nvim-treesitter/issues/4693

I made a PR with the change you recommended here: https://github.com/jose-elias-alvarez/null-ls.nvim/pull/1533

I am new to lua and neovim development in general. Is there a reason to use pcall over xpcall? It seems like it would have been a lot easier to figure this bug out if I had gotten some sort of alert or log that this error happened, but pcall apparently swallows any error into the void.

Edit: I read up more on pcall. It does return the error message if there is one. todo_comments should probably log the error if there is one returned.