Syntax highlights available on file open.

[dgriffith0]

Feature description

Recently migrated off rust tools and the only difference I'm noticing is that the syntax highlighting does not kick in until after rust analyzer completes, where as in rust tools it was immediately available. I only notice this on the first file I open. If the analyzer is running, and I open a different file in the project, I see syntax highlighting, but the initial file will only be highlighted after analyzer completes.

[mrcjkb]

Hey 👋

rustaceanvim doesn't do syntax highlighting (neither does rust-tools).
You want nvim-treesitter and the tree-sitter parser for Rust for that.

rust-analyzer does provide semantic tokens that neovim uses for syntax highlighting, but when they become available depends on the startup time of rust-analyzer. rustaceanvim has no influence on that.

Are you sure you were using the same environment with both rust-tools and rustaceanvim?

Closing and converting to a discussion.

[LennyPhoenix]

Hi, I'm getting a similar problem. I noticed that running :TSEnable highlight re-enables treesitter, but its odd that its disabled in the first place. This isn't persistent too, I need to rerun it every time I start my editor.

[mrcjkb]

Do you have anything defined in your ftplugin/rust.lua or after/ftplugin/rust.lua?

For me, tree-sitter highlights not getting enabled is usually a sign that an error was thrown in a filetype plugin or autocommand.
Often (especially when opening a file directly, by passing it as a CLI argument), Neovim will suppress the error messages for some reason.

Sometimes, it helps to call :messages. If that doesn't output anything, I would suggest you bisect your filetype plugins/autocommands for what might be throwing an error.

[LennyPhoenix]

I'm actually not using the ftplugin config:

Here's my rustaceanvim config:

local function setup_rust()
    vim.g.rustaceanvim = {
        server = {
            on_attach = function(_, bufnr)
                set_keybinds(bufnr)
                require("which-key").register({
                    ["<Leader>l"] = {
                        a = { "<Cmd>RustLsp codeAction<CR>", "Code Actions" },
                        c = { "<Cmd>RustLsp openCargo<CR>", "Open Cargo.toml" },
                        p = { "<Cmd>RustLsp parentModule<CR>", "Parent Module" },
                        R = { "<Cmd>RustLsp runnables", "Runnables" },
                        D = { "<Cmd>RustLsp debuggables", "Debuggables" },
                        j = { "<Cmd>RustLsp joinLines<CR>", "Join Lines" },
                        l = { "<Cmd>RustLsp renderDiagnostic<CR>", "Line Info" },
                    },
                    ["<A-k>"] = { "<Cmd>RustLsp moveItem up<CR>", "Move item up" },
                    ["<A-j>"] = { "<Cmd>RustLsp moveItem down<CR>", "Move item down" },
                    K = { "<Cmd>RustLsp hover actions<CR>", "Documentation" },
                }, { buffer = bufnr })
            end,
        },
    }
end

:messages also outputs nothing.

This is the diff, I don't really see anywhere that would be throwing an error (especially a silent one). Another plugin's update could have potentially fried something?

Do you have a workaround for now, or should I just call TSEnable highlight in on_attach?

[mrcjkb]

I don't have a workaround, because I can't reproduce the issue. Tree-sitter highlights are working fine for me.

I recommend you start troubleshooting from a minimal config (see the readme's troubleshooting guide), gradually adding plugins and configs until you can reproduce it.

You could also try bisecting your on_attach function.

[LennyPhoenix]

For now I've just enabled treesitter manually in on_attach. I'll properly debug later.

[mrcjkb]

I also noticed your diff has an update to nvim-treesitter. Have you tried rolling back that one?

[dgriffith0]

syntaxhighlight.mp4

Here is a video of the behavior I am seeing. The syntax highlighting works, you can see it's just delayed until after the analyzer completes. It's even stranger that it works in the preview window, and if I switch from the first file I opened. Feel free to skip to about 40s to skip the analyzer running.

[mrcjkb]

Thanks. It's clear from the video that you have a lot of plugins loaded. The fact that I can't reproduce this myself tells me it's probably caused by another plugin that conflicts with rustaceanvim, but doesn't conflict with rust-tools for some reason.

As I mentioned in the other thread, I recommend you start troubleshooting from a minimal config (see the readme's troubleshooting guide), gradually adding plugins and configs until you can reproduce it.

Another thing I noticed is that you are using Windows. If you can reproduce it using Windows with the minimal config, then that would mean that in your specific case, rustaceanvim might be throwing an error somewhere that it doesn't throw on Linux or Darwin and that is getting suppressed by Neovim.
If that's the case, then please use the bug report issue template, which contains fields that you can fill out to help with troubleshooting.

[dgriffith0]

I've done a little digging and found that If i open the file via :Telescope projects I don't get the highlighting. Opening via recent files works fine.

[dgriffith0]

I noticed the same if I try to open the file from terminal directly, and I am seeing an error:

Error detected while processing BufReadPost Autocommands for "*":
Error executing lua callback: ...coop/apps/neovim/current/share/nvim/runtime/filetype.lua:24: Error executing lua: ...coop/apps/neovim/current/share/nvim/runtime/filetype.lua:25: BufReadPost Autocommands for "*"..FileType Autocommands for "rust"..FileType
Autocommands for "*"..function <SNR>1_LoadFTPlugin[19]..script C:\Users\dgrif\AppData\Local\nvim-data\lazy\rustaceanvim\ftplugin\rust.lua: Vim(runtime):rustaceanvim: Invalid config: dap.configuration.env: expected string, got table
stack traceback:
        [C]: in function 'nvim_cmd'
        ...coop/apps/neovim/current/share/nvim/runtime/filetype.lua:25: in function <...coop/apps/neovim/current/share/nvim/runtime/filetype.lua:24>
        [C]: in function 'nvim_buf_call'
        ...coop/apps/neovim/current/share/nvim/runtime/filetype.lua:24: in function <...coop/apps/neovim/current/share/nvim/runtime/filetype.lua:10>
stack traceback:
        [C]: in function 'nvim_buf_call'
        ...coop/apps/neovim/current/share/nvim/runtime/filetype.lua:24: in function <...coop/apps/neovim/current/share/nvim/runtime/filetype.lua:10>

[mrcjkb]

Ah, that error message helps a lot 😄
It appears to be due to a bug that was introduced in #93
(very strange that I haven't encountered it myself yet).

It should be fixed with #244.

[dgriffith0]

Thanks that fixed it for me!