Refactor htmlify.p6

[JJ]

There are a number of issues involving htmlify.p6. There is also some repeated code, for instance badchars-ntfs is redefined in htmlify.p6 although it's included in the module, and badchars-unix is re-defined with a different value. htmlify.p6 has lots of methods that could maybe be moved to Htmlify.pm6, and then there a group of methods: viz-, write- ...
I wonder if we could kinda take a look at it and suggest some improvements to work on, speed and otherwise. Or, as suggested, just ditch it and change to a dynamic website.

[tisonkun]

👍 on this.

As Perl 6 has been spreading wider and wider, the site docs.perl6.org becomes (at least one of) the main approach people learning Perl 6 (for overview, for details) and the best manual to look up. That is, our doc site is significant.

#1090 said "It would be nice if the docs have the same design as the main perl6.org website. For consistency." and got some approves, well, it looks not that critical now

Broken links are caused by 1. how we escape chars (#1677 #1382 #1358 ) 2. we support many convenient, shorthand L<> （#1656 ）

For all that, we might need a branch or a distinct repo to do "REFACTOR", for keeping the current site serves. But at first, let's think about !!what we wish the site to be!!, which is more about "BUILD" and "SITE" instead of "DOC", our documentation is mostly elegant and useful.

Good luck @JJ for reading patchy scripts (https://github.com/perl6/doc/commits/master?after=5d73d9a99c98ed727cd9d8d4a9fe8e80d4cf3a2e+250&path%5B%5D=htmlify.p6) In htmlify.pm6, there is code which provides write-disambiguation-files for convenient sharing(have you ever arrived those pages?), and code which solves the issue of the local file names replace-badchars-with-goodnames

[Altai-man]

Or, as suggested, just ditch it and change to a dynamic website.

I am personally 👍 on that, but we need to decide what functionality should be available on backend, write some tech docs e.g. describe formats, inputs, outputs, etc. If we want a (e.g. postgres) database, we need to specify how things should work locally, how update process works etc.

In any case, I think that even if it was useful and good enough in past, now a single "god" script that does everything and where you need to be a magician to patch something with a bunch of old bugs nobody can help with, is less than awesome and I would doubt we want to spend time trying to improve it.

I probably can invest some time in backend writing, but firstly we("I" even) need some good design agreement/specification to follow that is "by design" free from known bugs of current docs website.

[JJ]

One of the main problems here is that every time you do a little change you have to rerun everything to see if it comes out right. First step in refactoring would be to spin off most of it to modules that could be tested independently...