proposed reworking; requesting smcv take another look

[git.ikiwiki.info.git] / doc / plugins / contrib / i18nheadinganchors / discussion.mdwn

diff --git a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
index ec6568010b88cf9586d2b1555139cbc4bcecf404..a172e5ac46a2a6e8151fb6271997ec78afc22c3c 100644 (file)
--- a/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
+++ b/doc/plugins/contrib/i18nheadinganchors/discussion.mdwn
@@ -84,6 +84,10 @@ or similar.
 > It's not a bug, it's a limitation. :) But sure, it's a thing. It's an issue in
 > headinganchors as well of course. -- [[anarcat]]
 
 > It's not a bug, it's a limitation. :) But sure, it's a thing. It's an issue in
 > headinganchors as well of course. -- [[anarcat]]
 

+>> No, current/historical headinganchors has a different bug: it ignores headings
+>> that have any attributes, and does not generate anchors for them. That gives it
+>> degraded functionality, but no information loss. I think that's less bad. --s
+

 I think we should try to use an existing ID before generating our own, with the
 generation step as a fallback, just like Pandoc does. If a htmlize layer like
 Text::MultiMarkdown or Pandoc is generating worse IDs than this plugin, the
 I think we should try to use an existing ID before generating our own, with the
 generation step as a fallback, just like Pandoc does. If a htmlize layer like
 Text::MultiMarkdown or Pandoc is generating worse IDs than this plugin, the