In reply to @asymmetric:matrix.dapp.org.uk
Yep, I think I know of them thanks to your post which gathers them all. I was more asking if there’s any concerted effort to get this all organized, improved and merged. If not I’d like to take this on, and could of course use some help from people who have put effort in it so far

In reply to @johannes.kirschbauer:scs.ems.host
I want to share my POC with the documentation team: https://hsjobeki.github.io/nix-doc-comments/reference/lib/debug/lib-debug-runtests/ Fully automated reference manual for the whole api surface of nix. In my vision this could replace: https://nix.dev/reference If you are interested into implementation details; it requires the rfc-145 and migrated-comments (according to the rfc) in nixpkgs. (This is still a POC so expect bugs and beeing incomplete)

In reply to @fricklerhandwerk:matrix.org
There are 1-2 open PRs to the Nixpkgs manual by Robert Hensing (roberth)

FWIW, what I don't like about this format is that it is incompatible with Git's tree-ish format :[<n>:]<path>.

See:

• [Git Glossary](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddeftree-ishatree-ishalsotreeish
• Git Revisions

FWIW, what I don't like about this format is that it is incompatible with Git's tree-ish format :[<n>:]<path>.

See:

• [Git Glossary](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddeftree-ishatree-ishalsotreeish)
• Git Revisions

FWIW, what I don't like about this format is that it is incompatible with Git's tree-ish format :[<n>:]<path>.

See:

• Git Glossary
• Git Revisions

FWIW, what I don't like about this format is that it is incompatible with Git's tree-ish format <rev>:[<n>:]<path>.

See:

• Git Glossary
• Git Revisions

i've been mentioned directly here, not sure why, but anyway: as the docs team, do we have anything to say in this regard? Or can I go ahead and say "No blockers from the doc team"?

I think it's a no-brainer but wanted to check with someone else first

two questions:

1. can/should we sync this with the members on github?
2. why are we enableFeatureFreezePing = true?

Als Antwort auf @fricklerhandwerk:matrix.org
This looks great. Still, as @roberth suggested elsewhere recently, we should not encourage using builtins to keep separation of concerns. I suggest rendering what you have to the Nixpkgs manual. It would also avoid getting into hairy consistency problems between Nix and Nixpkgs documentation. The nix.dev reference section should ideally consist only of links to the manuals, but some things are currently hard to do in an ideal way.