-
-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jump‐to‐definition for packages, library functions and options #538
Comments
Hi @emilazy , Thanks for suggestions on this project ❤️ . Currently
Yes, supporting selection effectively resolves this.
I see, it is generally ugly to have
What is the "native" option documentation?
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). |
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).
The |
I suppose this feature has already implemented in #526 ? |
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. |
I can only visit
|
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
andlib
have obvious assumed referents, and an argument that matches a Nixpkgs attribute could be assumed to come fromcallPackage
; there might be some subtleties around ecosystem‐specificcallPackage
functions here, but it should at least work reliably for things inpkgs/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 likenixpkgs-‹version›
) could be assumed to match the structure of the Nixpkgs flake.pkgs.‹name›
could be assumed to point to a Nixpkgs package definition if the package
‹name›exists. This is already done by e.g. the
with pkgs; [ … ]logic – it could be used for all variables named
pkgs` with an unknown definition, or just in cases that match the logic in heuristics 1 and 2? #552support completions for lib #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
home-manager
options suggested innixosConfigurations
and vice-versa #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 :)
The text was updated successfully, but these errors were encountered: