Open emilazy opened 1 month ago
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).
I see, it is generally ugly to have
nixdoc
as an external source for documentation. Why not just read that file again by ourselves? AFAIKnixdoc
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.
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 ?
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.
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.[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 :)