Pkldoc generates broken page anchors

[translatenix]

Searching the standard library docs, I noticed that I always land at the top of the page, not at the function I search for. For example, searching for sort takes me to https://pkl-lang.org/package-docs/pkl/current/base/Collection.html#sort(). But #sort() doesn't exist, so I land at the top of the page. Inspecting the page source, I found that id attributes are erroneously percent-encoded:

<div id="sort%28%29" class="anchor">

[bioball]

Thanks for the error report.

Although, it's not strictly necessary, the percent-encoding there is intentional (we are using java.net.URLEncoder underneath the hood to encode links and anchors).

We should similarly run links from the generated search index through URLEncoder.

[translatenix]

Although, it's not strictly necessary, the percent-encoding there is intentional (we are using java.net.URLEncoder underneath the hood to encode links and anchors).
We should similarly run links from the generated search index through URLEncoder.

Unnecessarily obfuscating Pkldoc URLs will result in a worse user experience.
Swift and Scala API docs are fine with parentheses in URL paths/fragments, as is the URL spec.

https://developer.apple.com/documentation/swift/array/sorted(by:)
https://www.scala-lang.org/api/2.13.5/scala/collection/SeqOps.html#sortWith(lt:(A,A)=>Boolean):C
https://url.spec.whatwg.org/#path-percent-encode-set
https://url.spec.whatwg.org/#fragment-percent-encode-set

From https://docs.rs/crate/percent-encoding/2.3.1 (emphasis mine):

When encoding, the set of characters that can (and should, for readability) be left alone depends on the context.

[bioball]

Yup, it definitely doesn't need to encode parentheses. It'd certainly be an improvement to not encode them here.