Inconsistent index escaping

[0branch]

Problem

The current escaping rules seem to be inconsistent between anchor names and corresponding index entries.

See [df15cce] for the latest example of this:

• Anchor name on the page: index-entry-declarator_blocks_%23|
  • Index entry: #index-entry-declarator_blocks_%2523%7C
• Anchor name on the page: index-entry-declarator_blocks_%23=
  • Index entry: #index-entry-declarator_blocks_%2523%3D

Chrome and Safari can resolve these links while Firefox apparently cannot (i.e., clicking #| in the search dropdown will take the user to the top of /language/pod rather than to the anchored declarator block section).

Suggestion

Ensure that the escaping used for anchors is also used in the index (i.e., address the inconsistency). In the above, page anchors should use <%7C %3D> rather than unescaped <| =>.

[JJ]

Please, @cfa , can you check this out?
At any rate, well, let's say that all the indexing thing is less than optimal. Thanks for the report.

[cfa]

Sure, I'll take a look.

[cfa]

First pass: it looks like rewrite-url-logged is called from write-search-file; this is what's mapping
#index-entry-declarator_blocks_%23= to #index-entry-declarator_blocks_%2523%3D via rewrite-url in Pod::Htmlify.

The anchor for the X<> ref (containing a literal '=') is generated by pod2html (exported by Pod::To::HTML). So, it seems that the problem is divergent escaping logic in rewrite-url vs. pod2html.

Will keep digging.

[cfa]

Re: escaping, I think there are two related issues:

1. rewrite-url escapes = as %3D; pod2html does not
2. rewrite-url is escaping already escaped URLs—%23 becomes %2523

Amusingly, It looks like %23%3D works in Firefox but not Chrome or Safari—so both these points need to be addressed for browser compatibility.

RfC @tbrowder @JJ (recent contributors to Pod::Htmlify).

[JJ]

Yep, I've been there and arrived to the point where it's easier to ditch it all and start all over again than keep patching it, because URLs are being generated, and then sent back and forth between pod and HTML, acquiring stuff on the process. Simply, the anchor generating part has to be rewritten, period. Actually, #1823 says the whole thing has to be rewritten.
So I would say let's acknowledge this, but let's leave it in the freezer for some time waiting major refactoring (which @finanalyst is doing) or rewriting of major parts of it.

[2colours]

Seems like this is not relevant to this repository anymore. Honestly, I can't even find these index-prefixed anchors, although I remember them. In any case - if there are problems, they should be consolidated under https://github.com/Raku/doc-website/.

[cfa]

Here are a few matches for index-entry.*% in the doc tree; the first few links I tried in the rendered site seem to be incorrect.

@2colours++ regarding escaping being the responsibility of the doc-website repo. Use of incorrect/broken index anchors in L<> links remains relevant here though. Might warrant a new issue?