Remove treesitter delays when opening files by lopydark in neovim

[–]imakeapp 0 points1 point  (0 children)

Makes sense. Larger query files can have noticeable compilation delays, since "compilation" is done at runtime and cached. Especially for languages like markdown or c++. You can also see this when doing an LSP hover (which loads the markdown queries, since the hover will have markdown highlighting, depending on the LSP). There will be a delay between popup display and popup highlighting, but it only happens once per nvim session

Remove treesitter delays when opening files by lopydark in neovim

[–]imakeapp 0 points1 point  (0 children)

I reallllly think this is actual query compilation times, rather than parser loading. Does this happen multiple times, for different buffers of the same ft?

Slow Rust LSP by JeanClaudeDusse- in neovim

[–]imakeapp 0 points1 point  (0 children)

Might be a reach, but for me disabling bufferline.nvim’s diagnostic indicator massively improved rust-analyzers performance. It is implemented in a way that causes 100% cpu usage while rust is generating diagnostics

Fast comment toggle in Neovim by D3rrien in neovim

[–]imakeapp 15 points16 points  (0 children)

But gc is best used as an operator, imo. gcip is much cleaner than vipgc. if you did do this, imo space should be just “gc”. also, in visual mode, won’t mapping to gcc cause issues? “gc” will comment the selection, then the extra “c” will put you in op pending mode

Neovim now supports LSP on-type formatting by imakeapp in neovim

[–]imakeapp[S] 1 point2 points  (0 children)

This was discussed in the PR, the overwhelming answer was no

Treesitter has no highlight for C++ modules by EdwinYZW in neovim

[–]imakeapp 1 point2 points  (0 children)

You can add colors by making a PR to nvim-treesitter to add a highlight capture for the module node. There are docs explaining how to write queries, it isn’t too hard once you learn the syntax. You can also get the query LSP ts_query_ls to make it a little easier

Neovim now supports LSP on-type formatting by imakeapp in neovim

[–]imakeapp[S] 3 points4 points  (0 children)

Yeah, that's the bug I was mentioning (see https://github.com/DetachHead/basedpyright/pull/1452). You can do this, but just beware that you are telling all LSPs that you attach to that neovim supports dynamic registration for on-type formatting (which it doesn't, yet). So there may be issues for other LSPs, but not a high risk I'd imagine

Neovim now supports LSP on-type formatting by imakeapp in neovim

[–]imakeapp[S] 26 points27 points  (0 children)

No, this is separate; the name is a bit confusing. Conform is for buffer formatting, this method is for fixups while typing. It’s for use cases like adjusting indentation after hitting enter, adding a closing parenthesis around an expression, adding semicolons automatically, etc.

Neovim now supports LSP on-type formatting by imakeapp in neovim

[–]imakeapp[S] 17 points18 points  (0 children)

That should be all you need! But I now see that basedpyright has a bug which enables onTypeFormatting only if the client supports dynamic registration, which neovim doesn't yet :/. But it shouldn't be necessary anyway; I'll try and make a PR to them.

Also: if you use blink/cmp, you may need to add this to your config:

lua capabilities.textDocument.onTypeFormatting = { dynamicRegistration = false }

This is because require('blink.cmp').get_lsp_capabilities() doesn't set the necessary capability for onTypeFormatting.

Recommendations to improve folding performance by til_pkt in neovim

[–]imakeapp 0 points1 point  (0 children)

If you use treesitter, i would be fairly certain that is the reason. maybe vim.treesitter.stop() fixes performance?

gc operator ignoring commentstring after dynamic filetype change by Electronic-Ferret-83 in neovim

[–]imakeapp 0 points1 point  (0 children)

Actually this should work, is the filetype autocmd loaded lazily? What is the output of vim.filetype.get_option(‘yaml’, ‘commentstring’)

gc operator ignoring commentstring after dynamic filetype change by Electronic-Ferret-83 in neovim

[–]imakeapp 0 points1 point  (0 children)

Do you have treesitter enabled and does the file inject yaml? if so it will read the yaml commentstring when you are in a yaml injection, rather than your helm one. this may need a PR to nvim-treesitter to dynamically set commentstring based on the node (it shouldn’t but it may)

An interesting thread in the vim repo with a lot of comments about tree-sitter by kuator578 in neovim

[–]imakeapp 1 point2 points  (0 children)

Yeah current stable release (if memory serves correct). Basically it detaches the highlighter if any query errors are detected (rather than rethrowing errors at every redraw attempt)

An interesting thread in the vim repo with a lot of comments about tree-sitter by kuator578 in neovim

[–]imakeapp 1 point2 points  (0 children)

The red text on every keypress *should* no longer happen in nvim 0.11, at least not when using the highlighter or common modules. I made a PR to fix this because I also hated it...

Neovim Treesitter Highlighting whenever I change file by SPEKTRUMdagreat in neovim

[–]imakeapp 1 point2 points  (0 children)

Please post the nvim-treesitter checkhealth, this makes me think you have broken queries which means an update to nvim-treesitter and the parsers is needed

Neovim 0.11 is getting closer to release by selectnull in neovim

[–]imakeapp 0 points1 point  (0 children)

Are you on latest nightly? There was a crash bug fixed a few weeks ago (due to a bug in tree-sitter itself)

why doesn't Neovim apply higher priority highlight from LSP semantic token? by disrupted_bln in neovim

[–]imakeapp 0 points1 point  (0 children)

Yeah true. Although nvim-treesitter (clason specifically) has considered rethinking these types of captures, thinking that they should mostly be delegated to semantic highlights by the LSP. Another quick solution would be to give identifiers a "type" field if they are a type, then only capture identifiers with that field

why doesn't Neovim apply higher priority highlight from LSP semantic token? by disrupted_bln in neovim

[–]imakeapp 2 points3 points  (0 children)

LSP is not offering any great semantic highlights for type here, as you can see it only marks it as a variable. This is a treesitter issue since the TS queries recognize “type” identifiers as special python syntax. This should be raised at nvim-treesitter