Passing macro as key to \kv@parse@normalized caused compatibility issue with thmtools

[muzimuzhi]

Both hyperref and thmtools use kvsetkeys as key-val setting mechanism. Unfortunately thmtools globally patches kvsetkeys to prevent expansion of key name, which causes compatibility issue with how hyperref handlers unknown key passed to pdfinfo. See a detailed analysis in muzimuzhi/thmtools#34 (comment).

I fully understand that it's all thmtools' fault to patch hence change the behavior of kvsetkeys. But given currently it's hard to know why such patch was needed at that time (at least 10 years ago) and whether removing or modifying it will cause regression problems, could hyperref adapt to not use macro as key passed to \kv@parse@normalized?

diff --git a/hyperref.dtx b/hyperref.dtx
index 33c8fa1..ca6e373 100644
--- a/hyperref.dtx
+++ b/hyperref.dtx
@@ -6390,14 +6390,14 @@
           \HyInfo@AddonList
           \HyInfo@do{\HyInfo@Key}%
         }%
-        \kv@parse@normalized{%
+        \expandafter\kv@parse@normalized\expandafter{%
           \HyInfo@Key={#2}%
         }{%
           \kv@processor@default{pdfinfo}%
         }%
       \fi
     \else
-      \kv@parse@normalized{%
+      \expandafter\kv@parse@normalized\expandafter{%
         \HyInfo@Key={#2}%
       }{%
         \kv@processor@default{pdfinfo}%

[u-fischer]

sure no problem. In the long run hyperref will stop to use kvoptions anyway. Regarding theorems: I'm testing in the testthm branch if one can simplify the theorem patches and correct the problem that destinations are lost if a theorem starts with a list. Could you test if this gives (obvious) problems with thmtools?

[muzimuzhi]

Regarding theorems: I'm testing in the testthm branch if one can simplify the theorem patches and correct the problem that destinations are lost if a theorem starts with a list. Could you test if this gives (obvious) problems with thmtools?

Sure. And maybe https://github.com/T-F-S/tcolorbox can be informed as well.