Jump‐to‐definition for packages, library functions and options

[emilazy]

Is your feature request related to a problem? Please describe. Using Nix, especially working on Nixpkgs, involves an awful lot of grepping over the Nixpkgs code to find definitions. It would be great to have it in the editor instead.

Describe the solution you'd like I think there are some pretty simple heuristics that would work for the majority of cases here:

• [ ] If the entire file is a function expression, heuristics can be used: pkgs and lib have obvious assumed referents, and an argument that matches a Nixpkgs attribute could be assumed to come from callPackage; there might be some subtleties around ecosystem‐specific callPackage functions here, but it should at least work reliably for things in pkgs/by-name. (There’s also things like NixOS tests which don’t have this exact form but have a similar predictable structure, but that’s probably not very important for a basic implementation of this feature.)

• [ ] In a flake outputs definition, nixpkgs (and perhaps variants like nixpkgs-‹version›) could be assumed to match the structure of the Nixpkgs flake.

• [x] #552

• [x] #495 lib.‹name› could be treated equivalently for Nixpkgs library definitions.

• [ ] Option definitions can be inferred in the same way they are for completion, though https://github.com/nix-community/nixd/issues/486 complicates this in the case where there’s ambiguity.

This could also enable documentation‐on‐hover for these (nixdoc for library functions, description/longDescription/etc. for packages, and the native option documentation), which would be fantastic!

Describe alternatives you've considered Continue getting really fast at using ripgrep :)

[inclyc]

Hi @emilazy ,

Thanks for suggestions on this project ❤️ .

Currently nixd-attrs-eval is used for evaluating "nixpkgs" attribute set. It is basically working except lib completion, and I think lib will not be very difficult.

pkgs.‹name› could be assumed to point to a Nixpkgs package definition if the package

Yes, supporting selection effectively resolves this.

This could also enable documentation‐on‐hover for these (nixdoc for library functions,

I see, it is generally ugly to have nixdoc as an external source for documentation. Why not just read that file again by ourselves? AFAIK nixdoc is based on rnix-parser and the parser is not really maintained.

the native option documentation)

What is the "native" option documentation?

Continue getting really fast at using ripgrep :)

No, that's not an alternative 😄 . This project exists, and aims to replace "grepping" technology used in nix community for years. Theoretically programming languages cannot be fully analyzed without "AST", not just DFAs (regexp).

[emilazy]

I see, it is generally ugly to have nixdoc as an external source for documentation. Why not just read that file again by ourselves? AFAIK nixdoc is based on rnix-parser and the parser is not really maintained.

Ah, I just meant the RFC 145 comment syntax / CommonMark format / etc. used by nixdoc; I should probably have said that instead. That would be the standard for documenting “library values” (as opposed to options or packages).

What is the "native" option documentation?

The type/description/default{,Text}/example{,Text} option attributes, like the option documentation in the manual shows.

[inclyc]

option attributes, like the option documentation in the manual shows.

I suppose this feature has already implemented in https://github.com/nix-community/nixd/pull/526 ?

[emilazy]

Ah, so it is! Maybe there’s some issue with my editor integration that made it seem not to work, or maybe it’s just because of the ambiguous option sets I have in my configuration. I’ll report an issue if I manage to reproduce it.