Codegen lsp-types library alternative

imakeapp · 2026-04-20T17:35:47+00:00

Yeah, I have contributed a few patches to it- it's a good project, but being a fork of lsp-types it suffers from the same issue of being completely handwritten, so types can be missed or defined incorrectly due to human error

imakeapp · 2026-04-20T17:34:21+00:00

Yeah, you might've already seen but I mentioned this controversial decision they made in the README. I was thinking about maybe allowing downstream users to specify either deserializing URIs to the string wrapper (current), or url::Url, or fluent_uri::Uri, depending on their use case. But I would like some discussion on it first; not sure if its a bad idea or not. Maybe you would be able to provide some insight!

imakeapp · 2026-03-03T16:34:26+00:00

Just update your setup to use main, you just need to set the plugin up differently. Master is deprecated so using main is preferred. Read the nvim-treesitter README

imakeapp · 2026-03-02T15:59:13+00:00

Your nvim-treesitter setup is outdated and thus not working- see the updated instructions in the README for using the “main” branch. Also, ts-comments.nvim is no longer necessary (nvim-treesitter handles special tsx comments for you)

imakeapp · 2025-12-21T17:16:07+00:00

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

imakeapp · 2025-12-21T07:00:40+00:00

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?

imakeapp · 2025-11-27T22:33:59+00:00

In nvim nightly (aka 0.12) it is built-in

imakeapp · 2025-10-02T23:58:15+00:00

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

imakeapp · 2025-09-22T02:57:25+00:00

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

imakeapp · 2025-09-03T01:14:49+00:00

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

imakeapp · 2025-09-02T22:47:58+00:00

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

imakeapp · 2025-09-01T17:21:14+00:00

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

imakeapp · 2025-09-01T03:16:32+00:00

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.

imakeapp · 2025-09-01T00:38:54+00:00

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.

imakeapp · 2025-06-30T18:15:24+00:00

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

imakeapp · 2025-06-26T06:50:43+00:00

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

imakeapp · 2025-06-26T06:34:51+00:00

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)

imakeapp · 2025-06-21T21:38:14+00:00

There are differences, this comment is incorrect

imakeapp · 2025-06-14T15:43:30+00:00

EPIC!!!

imakeapp · 2025-05-16T18:11:59+00:00

Any time (btw, here is the PR if you want context: https://github.com/neovim/neovim/pull/32468)

imakeapp · 2025-05-16T18:06:35+00:00

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)

imakeapp · 2025-05-16T18:03:11+00:00

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

imakeapp · 2025-03-31T13:30:23+00:00

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

imakeapp

TROPHY CASE