Comment by ~adjuvant on ~technomancy/fennel
See Fennel shows the same problem. In both directions. 141791343654238 => 141791343654240.0
Ticket created by ~adjuvant on ~technomancy/fennel
Fennel with LuaJIT compiles
141791343654238into1.4179134365424e+14(141791343654240).This does not happen with PUC Lua 5.3.
Welcome to Fennel 1.4.2 on LuaJIT 2.1.1693350652 Linux/x64! Use ,help to see available commands. >> 141791343654238 1.4179134365424e+14 >> (string.format "%0.f" 141791343654238) "141791343654240"Welcome to Fennel 1.4.2 on PUC Lua 5.3! Use ,help to see available commands. Try installing readline via luarocks for a better repl experience. >> 141791343654238 141791343654238 >> (string.format "%0.f" 141791343654238) "141791343654238"
Comment by ~adjuvant on ~xerool/fennel-ls
Some suggestions from a fellow Nix user (though without much flake experience).
The nix flake boilerplate is unfortunate, but necessary for flake users. Benefits of flakes are, among other things, a unified interface for better inter-op between nix-based tools and built-in dependency lock support. Yes, the package.nix is the only real "fennel-ls" specific code. Yes, it is quite normal to depend on flake-utils. And no, it is not a "dev dependency". Rather a framework for creating simpler flakes. "Pure" flakes have even more boilerplate if you want to support more than a single system type. E.g. not only
x86_64-linux.Depending on
makeis no problem at all, asmkDerivation(and you do want to keep that one) itself implicitly depends onmakeanyway, because it is its default build tool. (And Nix can't do "partial compilation or anything fancy" either.)But I am concerned with the needlessly detailed Readme instructions.
- Either you are a Nix user and know how to
nix runandnix develop. Or you are not, and do not care about this section at all. One sentence to acknowledge the existence of "nix support" would be enough?- Imperatively modifying a system with
nix-env(and nix profile?) is highly discouraged, isn't it? Better show anix runinvocation for ad-hoc usage, or a declarative example for permanent residence. For example, how to import the flake into a NixOS system configuration?- "NixOS" is mentioned quite a lot, but there does not seem to be anything NixOS specific happening here. Nix, the package manager, is operating system independent. One could use the same commands on Ubuntu or even MacOS.
So, yes, just for "Nix support", a simple
default.nixwith roughly the contents ofpackage.nixwould be enough. But flakes do have their advantages. My favorite is the following:$ nix run https://git.sr.ht/~grenewode/fennel-ls/archive/nix-support.tar.gz -- --help USAGE: fennel-ls [--check file] [--server]Nix transparently downloads and builds fennel-ls :)
Ticket created by ~adjuvant on ~xerool/fennel-ls
When used in the argument list of a function, the & itself is marked as "unused definition".
(λ foo [& args] ; unused definition: & (print 42))
When the & is used to destructure a list, the
xsis not marked as unused.(let [[a b & xs] [1 2 3 4 5]] (print a b))
Ticket created by ~adjuvant on ~xerool/fennel-ls
Opening a file outside of a workspace crashes the server.
rootUriisnull.$ codium foo.fnl
Part of the trace output:
Sending request 'initialize - (0)'. Params: { "processId": 4060, "clientInfo": { "name": "VSCodium", "version": "1.78.2" }, "locale": "en", "rootPath": null, "rootUri": null, "capabilities": { ... }, "initializationOptions": { ... }, "trace": "verbose", "workspaceFolders": null } Received response 'initialize - (0)' in 171ms. Result: { ... } Sending notification 'initialized'. Params: {} Sending notification 'textDocument/didOpen'. Params: { "textDocument": { "uri": "file:///home/user/test/foo.fnl", "languageId": "fennel", "version": 1, "text": "(λ foo [& args]\n (print args))\n\n(λ 24)\n" } } Sending notification 'workspace/didChangeConfiguration'. Params: { ... } lua: ...um/User/globalStorage/adjuvant.fennel-ls/fennel-ls.0.4.2:7237: attempt to call a nil value (method 'sub') stack traceback: ...um/User/globalStorage/adjuvant.fennel-ls/fennel-ls.0.4.2:7237: in upvalue 'startswith' ...um/User/globalStorage/adjuvant.fennel-ls/fennel-ls.0.4.2:7242: in function 'fennel-ls.utils.uri->path' ...um/User/globalStorage/adjuvant.fennel-ls/fennel-ls.0.4.2:7602: in function 'fennel-ls.searcher.add-workspaces-to-path' ...um/User/globalStorage/adjuvant.fennel-ls/fennel-ls.0.4.2:8141: in function 'fennel-ls.compiler.compile' ...um/User/globalStorage/adjuvant.fennel-ls/fennel-ls.0.4.2:7435: in function 'fennel-ls.state.set-uri-contents' ...um/User/globalStorage/adjuvant.fennel-ls/fennel-ls.0.4.2:528: in function <...um/User/globalStorage/adjuvant.fennel-ls/fennel-ls.0.4.2:517> (...tail calls...) ...um/User/globalStorage/adjuvant.fennel-ls/fennel-ls.0.4.2:8944: in function <...um/User/globalStorage/adjuvant.fennel-ls/fennel-ls.0.4.2:8933> (...tail calls...) [C]: in ? Connection to server got closed. Server will restart.
Ticket created by ~adjuvant on ~xerool/fennel-ls
Here is an example:
(it "works with unequal length replacements (does not produce double edits)" (check-rename "(λ [foo] (print foo))" 0 6 :something "(λ [something] (print something))"))Generated edits:
[{:newText "something" :range {:end {:character 19 :line 0} :start {:character 16 :line 0}}} {:newText "something" :range {:end {:character 7 :line 0} :start {:character 4 :line 0}}} {:newText "something" :range {:end {:character 7 :line 0} :start {:character 4 :line 0}}}]Result:
(λ [somethingething] (print something))Interestingly, the test would succeed if the variable names had the same length. But Visual Studio Code does not accept duplicated edits at all, even if they would technically produce the correct result.
Rename failed to apply edits
[error] Error: Overlapping ranges are not allowed!
Comment by ~adjuvant on ~xerool/fennel-ls
We could issue the 'workspace/configuration' request in response to the 'initialized' notification. But that would not help with the bad timing. The client will send the 'textDocument/didOpen' notification directly after 'initialized', and wont wait for our request. The only way this could work reliably is, if the server were to delay processing all notifications and requests, until the 'workspace/configuration' response is received. But I do not like that very much, as the server would need to buffer those requests and "replay" them after the configuration is received. Lots of special handling just for this one configuration request.
Another way, which I find more practical and intuitive, is to embed the configuration directly into the 'initialize' request. This way, we can easily ensure, that the configuration is set before anything else happens. This is how the rust-analyzer does it. (In addition to the 'workspace/configuration' request.) https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp-extensions.md#configuration-in-initializationoptions
Comment by ~adjuvant on ~xerool/fennel-ls
Earlier I wrote (https://lists.sr.ht/~xerool/fennel-ls/patches/43841)
Configuration is not possible, because there is no way to trigger a
workspace/didChangeConfigurationnotification, without the server requesting the section first.I was wrong. Of course there is a way to send arbitrary notifications with the vscode-languageclient library. Now I am sending the configuration notification. And it works.
However, I fear, we still have to send the configuration request to ensure that the configuration is loaded before anything else happens. Even if I send the
workspace/didChangeConfigurationdirectly after initializing the client, the firsttextDocument/didOpenstill occurs earlier.[Trace - 22:07:39] Sending request 'initialize - (0)'. [Trace - 22:07:40] Received response 'initialize - (0)' in 191ms. [Trace - 22:07:40] Sending notification 'initialized'. [Trace - 22:07:40] Sending notification 'textDocument/didOpen'. [Trace - 22:07:40] Sending notification 'workspace/didChangeConfiguration'. [Trace - 22:07:40] Received notification 'textDocument/publishDiagnostics'.