From 5ce1fd9f6cb8cf6243b92fef95b4705943ffef01 Mon Sep 17 00:00:00 2001
From: anarcat <anarcat@web>
Date: Fri, 17 Jan 2020 17:09:52 -0400
Subject: trying to bring this back in the pile :)

---
 .../contrib/i18nheadinganchors/discussion.mdwn     | 29 ++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
index a172e5ac4..7841467b2 100644
--- a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
+++ b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
@@ -69,6 +69,22 @@ supporting [IRIs](https://tools.ietf.org/html/rfc3987): `<a href="#visiting-北
 >> In practice, minor or old browsers are probably insecure anyway, so I don't care
 >> too much about supporting them perfectly... --s
 
+> After thinking more about this, I don't feel that IRIs are a good
+> solution. Sure, there are machine-readable ways of encoding
+> non-ASCII characters in URLs. But that's not the point here: the
+> point here is to have *human* readable URLs. In the example I give
+> in the plugin documentation, I mention the french word "liberté"
+> which can easily be transliterated to "liberte". By using the
+> RFC3987 scheme, we could use unicode directly in the links (`a
+> href="#liberté"`), but the actual URL would be encoded as
+> `#libert%e9`, which is really not as pretty.
+>
+> I understand you not wanting to introduce another dependency. And I
+> also worry about the transliteration not being stable across
+> releases. After all, it might not even be stable across Unicode
+> releases either! But I'm ready to live with that inconvenience for
+> the user-friendliness of the resulting URLs. --[[anarcat]]
+
 ----
 
 Documentation says:
@@ -102,6 +118,19 @@ htmlize layer, or stop using Text::MultiMarkdown.
 > for me to just override whatever attributes were there for testing and 
 > fixing this in the short term... -- [[anarcat]]
 
+> To bounce on this again: my problem with keeping existing IDs is
+> that it basically makes headinganchors fail to do anything if
+> something else adds the anchors. So I understand where you're coming
+> from with this, but that "bug" was introduced on purpose, to
+> actually fix a problem I was having.
+>
+> So I understand you might not want to *replace* headinganchors
+> completely with this module, but could we at least merge it in so I
+> wouldn't have to carry this patch around forever? :) Or what's our
+> way forward here?
+>
+> Thanks! -- [[anarcat]]
+
 ----
 
 <pre>Some long scrollable text
-- 
cgit v1.2.3