| 24 Aug 2023 |
 raitobezarius | Could we do something about this? | 22:34:21 |
| raitobezarius | e.g. a robots.txt to reduce its position wrt to SEO | 22:34:30 |
| raitobezarius | (we have users citing it in nixpkgs PRs) | 22:35:11 |
 proofconstruction | That makes sense - it's the nixpkgs manual I use when I go looking for something. The mdbook style is so much better than a 50km long page | 22:49:16 |
| raitobezarius | Indeed, the problem is that it's not fresh/outdated | 22:51:36 |
| raitobezarius | I honestly prefer the 50 km long page :P | 22:51:46 |
| raitobezarius | But I think offering both is not bad at all | 22:51:54 |
 ryantm | Many people have told me they like it better than the official manual. I should commit to an update at least every release. | 23:50:07 |
| ryantm | !00% not going to make my SEO worse in some way as long as people are telling me they prefer my manual rendering. | 23:55:40 |
| ryantm | I'll try to update it this weekend! | 23:58:35 |
| 25 Aug 2023 |
| raitobezarius | Thank you | 00:05:12 |
|  @dylandoesprogramming:matrix.org left the room. | 00:05:36 |
| raitobezarius | That being said, I feel like it would help a lot to get this "alternative" rendering merged somehow | 00:06:40 |
| raitobezarius | I don't have a big opinion on the rendering, but I personally find it hard to navigate the mdbook style and I prefer the long page, some prefers the mdbook and that's fine, we just have contributors who don't know what to do when folks are enforcing rules from the outdated mdbook manual | 00:07:29 |
| proofconstruction | Unifying the rendering infrastructure for all the manuals has been discussed often and is on the roadmap https://github.com/nix-community/projects/issues/6, but we don't have the time/energy/(funds to throw at it)/etc currently | 00:13:20 |
| raitobezarius | Understandable | 00:15:24 |
| ryantm | In reply to @proofconstruction:matrix.org
Unifying the rendering infrastructure for all the manuals has been discussed often and is on the roadmap https://github.com/nix-community/projects/issues/6, but we don't have the time/energy/(funds to throw at it)/etc currently This is why I made mmdoc in the first place. I wanted to make a documentation rendering system that was lightweight enough to be kept on as part of nixos-rebuild and didn't add to the closure size. | 13:44:17 |
| ryantm | Totally get that I didn't put in the effort to push it over the finish line though, wish I had that energy. | 13:54:31 |
| ryantm | I started updating it and it looks like it's mostly just compatible with the existing docs! I think I can make a super small diff that's not too invasive! | 15:01:00 |
| raitobezarius | you mean nrd or mmdoc or something else? | 15:06:26 |
|  @janik0:matrix.org joined the room. | 15:11:18 |
| ryantm | mmdoc | 15:13:33 |
| proofconstruction | In reply to @ryantm:matrix.org
I started updating it and it looks like it's mostly just compatible with the existing docs! I think I can make a super small diff that's not too invasive! While I think everyone on the docs team agrees that unification of rendering schemes for the manuals is preferable, we haven't had an in-depth discussion around migrating to mmdoc specifically, nor is there really even broad agreement on changing the current system yet. These ideas are very much still in the evaluation phase, rather than planning, so please don't do extra work that might not be used! | 20:12:05 |
| ryantm | proofconstruction: I'm not doing it because I expect you to use it, I'm doing it because I think mmdoc is cool technology that should exist on its own. If it happens to be the best way to solve the unification problem, great. | 20:40:49 |
| ryantm | In my mind, it has expanded beyond the scope of my original target use case. | 20:41:18 |
| proofconstruction | Speaking for myself, I also think it's cool (as mentioned, I generally consult your version of the manual rather than the official one), and I don't personally have objections to using it for the rendering unification project. Just wanted to ping you so you don't spend additional time on it for this purpose | 20:46:39 |
 Luc Perkins | How extensible is mmdoc, though? I remember playing around with it and I like it that it's lightweight, but how trivial/non-trivial would it be to provide things like admonitions, headings that are linkable on hover, TOCs, footnotes, and other not-quite-standard-Markdown-but-nonetheless-widely-used things? | 21:24:46 |
| Luc Perkins | * How extensible is mmdoc? I remember playing around with it and I like it that it's lightweight, but how trivial/non-trivial would it be to provide things like admonitions, headings that are linkable on hover, TOCs, footnotes, and other not-quite-standard-Markdown-but-nonetheless-widely-used things? | 21:24:54 |
| Luc Perkins | As far as I can tell, cmark is fairly rigid | 21:26:04 |
| Luc Perkins | (but I barely know C so my comb through the cmark codebase shouldn't be taken as final 😄) | 21:26:45 |
