We are pleased to share that a new version of the nimlangserver and the nim-lang.org vscode extension have been released.
The focus of the releases have been bug fixing and making a foundation to build upon.
We are quite excited about resuming the work on the vscode-extension and there are a few small quality of life improvements such as the initial work on integrating a debugger prettifier and the 'Debug Selected this file' command. The nimlangserver now supports inlay type hints, signature help (with reduces the noise in overloads) and has improved Windows support.
There have been also improvements to NimSuggest, including bug fixes, that are not yet released but will be available in the next release of Nim. The Nim codegen is also getting a boost and we are working on demangling function symbols for a better debugger experience.
The release notes for the nimlangserver are as follows:
added support for inlay type hints (requires Nim 2.0.2 or 1.6.18)
added version detection option -v / --version
added support for SignatureHelp
added support for notification verbosity option
various Windows bug fixes (notably, the 'cannot find the path' crash on startup and several others)
fixed autocomplete with recent versions of Visual Studio Code
fixed issues with remaining nimsuggest and nimlangserver processes after improper shutdown from the LSP client
fixed the display of status indication: 'Creating nimsuggest for {projectFile}'
fixed crash when rootUri is not set
fixed several stability issues and crashes
https://github.com/nim-lang/langserver/releases/tag/v1.2.0
The release notes for the nim-lang.org vscode extension are as follows:
added prettifier for Strings when debugging
added 'Debug Selected this file command`
added a setting to optionally set the lsp path
added option for controlling lsp verbosity
added notification when there is a newer lsp version available
added configuration option for enabling/disabling inlay type hints
added configuration keys for the exception hints
ux improvement: added shorcut in the current Nim file for run/debug
https://github.com/nim-lang/vscode-nim/blob/main/CHANGELOG.md
In future releases we want to keep improving NimSuggest, the debugger experience and bringing more stability and quality of life improvements to the nimlangserver and the vscode extension.
Thanks to the Nim team for their hard work on these improvements, to the community for their feedback, to the contributors for their contributions and special thanks to Status for sponsoring the development.
CodeLLDB is the recommended one. Probably we will end up making it a dependency of our extension. Notice there is an option to define the default target (lldb) called nim.debug.type so you can use another extension if you want.
type of debugger to use when using Nim: Debug selected file. The value is the same value as typically used in launch.json for the type attribute.
Congrats on the release.
Now I can abandon Konstantin Zaitsev's vscode extension, because after this round of improvements to the official extension, it works perfectly even when opening a random .nim file, without the need to open a folder.
Thanks to all the devs and sponsors behind this effort
I've been a pro on triggering this so far fixed issues with remaining nimsuggest and nimlangserver processes after improper shutdown from the LSP client
Hope this release will stop my process killing spree
upgraded but same problem as before. For example I have project with 2 targets: JS frontend (karax) and C backend, using this .vscode/settings.json
{
"nim.project": [
"src/back/back.nim",
"src/front/front.nim"
],
}
When I open vscode on the project, I see 1x nimlangserver + 2x nimsuggest processes. All is good. When I close vscode nimlangserver is not killed, one nimsuggest process goes <defunct> but not the other. If I reopen the same vscode project I now have 2x nimlangserver + 4x nimsuggest processes (1 <defunct>). After N repeats would have N nimlangserver + 2*N nimsuggest processes.Hi, @giaco. Can you check that your nimlangserver is the new version (running "nimlangserver -v" from the command line should print the version, if it's the new version), and that it's the only nimlangserver binary and it's in the PATH? If you're sure it's the new version, please file a bug report with as many details as possible (OS/distro, nimsuggest and nim versions, VS code version, and steps to reproduce, i.e. how you've installed them - choosenim, build from source, installed via package manager, using nimble, etc.):
Wow, I just pulled up some test code and saw the new type inlays!
Shout out to the guys working on the tooling. It just magically appeared.
Works like a bliss on Ubuntu 23.10.
Thanks @jmgomez
VScode:
Version: 1.87.0
Electron: 27.3.2
ElectronBuildId: 26836302
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Linux x64 6.5.0-21-generic snap
This page needs an update now: https://nim-lang.org/faq.html
> ## What about editor support?
> Visual Studio Code:
> Extension written in Nim https://marketplace.visualstudio.com/items?itemName=nimsaem.nimvscode
> Original Extension written in TypeScript https://marketplace.visualstudio.com/items?itemName=kosz78.nim
all the issues I had with vscode went away by removing choosenim
just let nimlangserver call nimsuggest directly and not via the proxy exe generated by choosenim
https://github.com/nim-lang/langserver/issues/184#issuecomment-1970096558
It's a simple matter of killing the process group and not just the proxies - https://stackoverflow.com/questions/392022/whats-the-best-way-to-send-a-signal-to-all-members-of-a-process-group
https://stackoverflow.com/questions/1230669/subprocess-deleting-child-processes-in-windows
a simple matter, yes, but one that has been haunting all choosenim + nimsuggest users since 2019
the problem is proxyexe.nim not proxying enough
https://github.com/dom96/choosenim/blob/master/src/choosenimpkg/proxyexe.nim