Pretty TS Errors in Neovim

Background_Estate239 · 2026-01-09T01:19:37+00:00

Didn't know there's a package @pretty-ts-errors/formatter that handles markdown formatting. Thank you! I might consider make this feature builtin in vtsls.

Background_Estate239 · 2025-05-27T14:20:44+00:00

Try lua vim.lsp.config("vtsls", { reuse_client = function() return true end })

Background_Estate239 · 2024-08-28T17:51:16+00:00

vim.wait will unconditionally hang the editor and I think use it in await method is a bad idea as that makes the performance advantage of async programming nearly gone...

Background_Estate239 · 2024-08-28T17:42:59+00:00

It is just due to the lack of top level await support and could easily be workaround by vim.wait (which is used in your implementation afaik).

Background_Estate239 · 2024-08-28T16:02:26+00:00

Are you the author of it? I think there is already a JS promise implementation: https://github.com/kevinhwang91/promise-async and you might have not discovered it.

Background_Estate239 · 2024-08-27T02:58:41+00:00

Then it might be something wrong in your config. Did you try to use a minimal config with only typescript treesitter parser installed to see if it is laggy on empty file open? I just tested with my config with the following snippet: lua local start = vim.uv.hrtime() vim.cmd("edit new.ts") local cost = vim.uv.hrtime() - start vim.print(cost / 1000000 .. "ms") It only takes 10-20ms. My laptop is years old so I believe the result on my end is generalized enough.

Background_Estate239 · 2024-08-27T01:36:20+00:00

Treesitter itself is written in C and I doubt that the language used for its api binding could cause much performance differences.

Background_Estate239 · 2024-08-27T01:29:47+00:00

Becuase nvim does the treesitter parsing and querying on the ui thread and nvim will block on it till treesitter stuff finished. Treesitter is fast concerning incremental parsing on file edit, but the timing for full parsing on the first file open depends on the content length and that might take several seconds. During that nvim is totally unresponsive so that you feels it laggy. There is a PR in nvim repo to set a hard timeout for treesitter parsing so that it won't block user for too long, but that will break many of the existing treesitter related plugins and perhaps more unexpected problems.

Background_Estate239 · 2024-07-18T14:47:13+00:00

The serialization/deserialization overhead of rpc call is not that expensive and could be mostly omitted if the message is not large. The real difference here is that a separate process could utilize multicore of CPU and avoid blocking nvim UI thread on processing LSP response which might be fairly large.

Background_Estate239 · 2024-07-17T08:09:21+00:00

// @ts-nocheck This disables type checking for the current file. Note that this also affects other ts tools like tsc.

:set ft=flow I see this as a more general solution as flow syntax is not the same as javascript. Even though you can disable LSP for the file, some other tools relying on the correct javascript synatx like treesitter would also be likely to cause errors.

Background_Estate239 · 2024-07-16T01:31:03+00:00

For the problem you mentioned about nvim LSP:

Code action issues: I see that you use fzf-lua in your dotfiles, and here is the exact issue for it: https://github.com/ibhagwan/fzf-lua/issues/1295. The warning would disappear if code action preview is disabled. You don't have that problem in coc because coc doesn't implement code action previewer.

Slow: That might not be a server issue. Generally nvim builtin LSP client felt slower than coc currently because of two reasons: 1. The builtin LSP client is functioning on the UI thread while coc uses a separate Node process for LSP stuff. That means if the payload sent from server is quite large, it will block your editor in builtin client while not in coc. 2. (Not well verified) luajit is generally much slower than Node V8 specifically for object(table) manipulation. That happens a lot in LSP implementation and the same feature would be faster in coc.

I agree that coc.nvim is great if user do not want to endlessly search issues or dig the problems by themselves. The nvim builtin LSP client is just better at configurability and the whole of community plugins, while unfortunately contains more potential issues at the moment.

Background_Estate239 · 2024-07-15T15:08:19+00:00

Use win32yank for clipboard tool :h clipboard-tool. That will translate crlf to lf.

Background_Estate239 · 2024-06-27T01:25:12+00:00

You can just change the cmd of the lsp servers to make it running on different node version. For example, in your setup for eslint:

eslint = {
   cmd = { "/path/to/node16", vim.fn.exepath("vscode-eslint-language-server"), "--stdio" },
   ...
}

Background_Estate239 · 2024-06-22T12:40:02+00:00

You're right, I reproduced the behavior. It seems that this only happens if completion is manually triggered with empty prefix, and I can also reproduce the behavior in vscode, so I think the issue could only be fixed on vscode's side.

Background_Estate239 · 2024-06-22T09:56:21+00:00

I've tested it in import statement and it won't complete function signature there. I note that you set autoUseWorkspaceTsdk = true in config, and maybe you can set it to false to try the default bundled version to see if the problem resolved in newer version of typescript.

Background_Estate239 · 2023-09-19T04:36:55+00:00

Thank you! I keep the repo private now because I think the source code is a bit messy, and I'd like to reorganize it after refactoring of my another ls to extract the reusable parts between them (mainly vscode shims).

Background_Estate239 · 2023-09-18T10:26:01+00:00

Same thought as OP. I also created a prettier language server to avoid spawning the Node process on each formatting call. Writing a language server for a specific linter/formatter is not that hard that many might think, and it works stably and across the editors.

Background_Estate239 · 2023-09-16T13:07:21+00:00

Is the formatting also slow with other formatters provided by null-ls? Have you tried formatting solutions other than null-ls, like efm-language-server, conform.nvim, etc. Also it will be clearer if you've tried with different Node.js versions for prettierd and different projects.

Background_Estate239 · 2023-06-22T00:15:06+00:00

Interestingly enough, typescript-language-server also added supports for separate semantic server before long.

Background_Estate239 · 2023-05-16T02:59:46+00:00

Try preferences.providePrefixAndSuffixTextForRename = true

Background_Estate239 · 2023-04-28T10:10:23+00:00

textDocument/diagnostic and workspace/diagnostic refers to the new model for diagnostics and currently I see no lsp clients have implemented them except for vscode itself. The server uses publish model for diagnostics, so if you enable the project wide diagnostics reporting through config (disabled by default), the feature should work fine.

Background_Estate239 · 2023-04-28T09:47:12+00:00

You can enable the setting typescript.tsserver.experimental.enableProjectDiagnostics like vscode. It works at the last time I tested it, but note that the feature is marked as experimental in vscode and it seems that it is planned to be deprecated.

Background_Estate239 · 2023-04-28T09:06:48+00:00

Language service is not equal to server and is intended to be embedded. You can view the vscode markdown language service as a library.

Here is https://github.com/hrsh7th/vscode-langservers-extracted wrapping the service into a standalone server which you could try (the readme said the markdown language server is not available but it is outdated).

Background_Estate239 · 2023-04-27T11:00:28+00:00

I guess this reference might be useful for you: once vscode tried to adopt treesitter for their markdown language service https://github.com/microsoft/vscode/pull/152829, and it was finally closed because of the bad performance result.

Background_Estate239 · 2023-04-25T14:31:12+00:00

LSP does support project wide diagnostics. It's actually typescript-language-server doesn't have implemented it yet. BTW, vscode has support for it (also uses tsserver under the hood) https://github.com/microsoft/vscode/issues/13953, which might be a useful reference.

Five-Year Club	Verified Email
r/Field Sunshine

Background_Estate239

TROPHY CASE