Possible features and ideas

[aaronjanse]

Here's are some informal ideas for things that we might want in rnix-lsp, some of which would be possible via evaluation. Feel free to add to this list:

• hover over an expression to view its value
• hover over a variable name to see documentation, extracted from comments nearby the variable's definition
• auto-complete for variable names, even within with statements
• goto-definiton across files
• caching function parameters (for UI purposes only), so that pkgs.withPackages ({rustPackages}: ...) would let us know the value of rustPackages based on pkgs
• auto-complete of attribute names for common patterns like functionName { /* attributes here */ }, maybe also use the comments next to paremeter definitions in the function source code
• nixos option hover docs
• nixos option autocomplete
• diagnostics for when a user-provided value (e.g. a nixos option value) fails assertions elsewhere
• understanding NixOS channels and flake inputs
• test suite

Some of these might not be possible, and we might not want others. But I thought I'd at least write them down somewhere.

[Ma27]

I think we should also make a plan when/what to release:

• I'm not sure how much has changed since 0.1.0 (I'm using git revs of this repo locally), but I'm planning to take another look at Consuming 30G when used via noevim coc #33 soon (perhaps it's completely gone with Enable incremental parsing via the LSP protocol #37, but I'm not sure) and would suggest to create a release then (depending on how much has changed, either 0.1.1 or 0.2.0).
• With a basic evaluator we probably want to consider doing a 0.3.0 (or 1.0?) then and see how to proceed after that :)

[Ma27]

As discussed with @aaronjanse via DM, we'll proceed here like this:

• 0.2.0 will be released when we've stabilized master. I think there are a few new useful features on it, but unfortunately a few issues (i.e. issues added to this milestone). When we're done here, we can release 0.2.0
• 0.3.0 will be released when we have a basic, working evaluator with arithmetic support and a few more useful things.

Further 0.* releases will be added while we integrate #38 into master and basically implement all the bullet-points from this issue. As soon as we're ready and kinda confident in everything (this may take a while, also due to personal constraints), we'll consider a 1.0 :)

[nrdxp]

We may be able to use something from lf-/nix-doc for the documentation hovering.

[Ma27]

That's a nice idea, will keep that in mind when we get to it, thanks! :)

[Kranzes]

I was considering updating rnix-lsp on nixpkgs to the latest commit because 0.1.0 is over a year old now, @Ma27 do you think 0.2.0 is close enough to be released for me to wait and update to that instead of using the latest commit of the master branch?

[Ma27]

@Kranzes there's still #33 open. While I have a hard time reproducing this (I encountered it twice in the last ~75 days), others experience it rather regularly, unfortunately. It doesn't mean I've given up though, however I'm currently lacking time & energy to investigate it more thoroughly, so in case you're affected by this as well, you'd have to be patient a little bit.

Apart from that, master is quite fine and usable, so the final decision is up to you, I'm afraid :)

[aaronjanse]

Thank you to @Ma27 and @fufexan for figuring out how to reproduce & possibly fix the memory leak: nix-community/rnix-parser#31.

If the crash goes away after merging that PR, I think it would make sense to tag a 0.2.0 release then update nixpkgs

[aaronjanse]

Another idea: in the expression with pkgs; [ htop ], should selecting htop show some annotation on pkgs, since that's why htop is in scope?

[Ma27]

I still remember quite a few occasions where nested with led to a fair share of confusion, so I'm all for it 👍

[figsoda]

some code actions would be nice, here are some that I can think of:

• prefetch hash of fetch* functions
• with to let inherit
• inline let variables
• foo.bar to let inherit (foo) bar; in bar
• move a block of code into let in
• move a block of code to a separate file
• { foo, bar }: ⟷ foo: bar:
• lib.optional ⟷ lib.optionals
• convert between types of hashes
• inherit (foo) bar ⟷ bar = foo.bar
• "foo" ⟷ ''foo''
• rec ⟷ lib.fix
• "foo{bar}baz" ⟷ "foo" + bar + "baz" (also for paths)

[aaronjanse]

Whoa, these ideas are so cool! Thank you so much @figsoda!

I especially love the idea of rnix-lsp helping fill in sha256 hashes. That would significantly improve my workflow while using Nix.

[aaronjanse]

Would it make sense to provide hard-coded builtins docs for when nix-unstable is not found?

[nrdxp]

once NixOS/nix#5527 is fleshed out, it should be a lot easier (hopefully) to show documentation on arbitrary functors as well 🤞

[RaitoBezarius]

Hi there, I really really think that the LSP idea is a very needed tool in the Nix community, esp. the sha256 autofill hash stuff and autocompletion with docs.

How much do you think it would be possible to get someone to work on this as a funded (Open Collective, grants?) gig in the future?

[milahu]

any news? how can i help?

also other tools like nix-gui are hitting this limitation.
we need an incremental evaluator for nix

this could be based on an incremental parser like

• tree-sitter-nix in C
• lezer-parser-nix in javascript

see my experiments in nixos-config-webui - javascript is nice for prototyping

related:
nix-community/rnix-parser#33 - error handling in select
#68 - excessive hover info
toros - nix evaluator in rust, based on nixel parser
nix-eval-lsp - proof of concept for intellisense (autocomplete, hover)
hazel - incremental editor with typed holes
#55 evaluate attribute sets
#45 evaluate arithmetic
#38 add evaluator
#66 evaluate lambdas
#65 autocomplete via evaluation

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/nix-eval-js-a-nix-interpreter-in-javascript/22182/1