Let’s give each other the gift of CommonMark this holiday season!
Since RFC 72 has been accepted, we can start converting Nixpkgs and NixOS manuals to CommonMark. The sooner we can get the old docs converted, the sooner we can reap the benefits of better output formats and easier contributions!
I probably missed some of the discussion around this, but would you recommend converting each docbook file ‘by hand’, or use a tool like pandoc for an initial pass and then manually fix up the generated markdown (as I’m sure it’s inevitable to do a fair bit of manual work to make it actually right)?
Before we start translating individual parts of the documentation: Do we have the tooling in-place to build the hybrid docs for the time being? It would be a pity to have less functional docs as outcome of this. Did the tooling discussion and integration into nixpkgs already happen somewhere?
Exactly, we need to agree on tooling first. This was kept out of the RFC, however the tooling and thereby extensions decides what information gets lost in the conversion. Especially when it comes to references.
Since we already support hybrid Docbook/Markdown sections (at least in the Nixpkgs manual), I don’t think it makes sense to mass convert the entire manual. That sounds too risky and too hard to split up the work.
It might be okay to pass a section through pandoc and then fix it up. I haven’t tested it.
The nixpkgs manual supports hybrid Docbook/Markdown sections. Looks like we’ll need to figure out what to do for NixOS.
No, not yet really. Based on the conversion efforts so far, we’ve run into these issues:
inter-section references
callouts
ShellSession code blocks let you highlight the $/# at the beginning
Yes, we’ll try to do our best. As has been discussed in the RFC, it may be necessary to sacrifice some feature to reach the end goal.
If anyone else runs into trouble with docbook tags being stripped like I did there is a work around.
You can escape any docbook code and have pandoc put it directly into the resulting document by putting it inside a code fence with this attribute on it.
Just a few tips for the people that is contributing.
Use github codespaces if possible to edit the files. It downloads the repo (~1.3GB) way faster than your home internet. Especially if you are from Brazil.
To test locally you can commit in your branch at your fork and push it, you can then download the tarball of the revision that will be way smaller than the whole repo. The url seems like https://github.com/username/nixpkgs/archive/codespaces-1.tar.gz. Untar it and do the nix-build inside the docs folder to test if its nice. You can also install a extension for markdown preview in the codespaces for better feedback loop.
If you are a vim fan, or even a normal user, you can save time replacing common tags to the markdown equivalents like <para> that just go away, <literal> that encloses with backticks and programlisting that is enclosed by backticks. The hard work is to normalize the unnumbered lists, indentation, the special symbols using &something; and wrapping <prompt>s into three backticks (because of the special symbols).
I converted <prompt> blocks into three backticks but without specifying language and converted <programlisting> into the language its written, that is mostly Nix.
For those that really want to contribute, many of them can be likely done with a pandoc conversion however please read over the generated markdown to make sure it’s good.