EditWithIdleX.py breaks a lot (3.6), extensionManager, idlexMain use nonexistent names
Opened this issue · 1 comments
I'll attach files first (much easier to see the diff).
Root cause - assumptions which "worked" by accident. It assumes that Python install was "for current user only" and that reg keys for IDLE were placed by Python install and use a dangerous hack. 3.6 doesn't place them at all => people gather info from the net and do it on their own, which ends up being more stable and versatile - but IdleX stumbles.
Attached files are not total solution but the missing part => total EditWithIdleX.py would need to handle 4 variants: HKCU and HKCR with the key name hacked to serve as MUIVerb string and with proper MUIVerb fields).
WIth proper MUIVerb settings reg keys are not
HKCU\Software\Classes\Python.File\Shell\Edit with IdleX\command @="..."
but
HKCR\Python.File\Shell\IdleXedit\command @="..."
HKCR\Python.File\Shell\IdleXedit\command
"MUIVerb"="Ed&it with IdleX"
This allow marking a shortcut letter and language variability (that's the "MUI" part in the name). "IdleXedit" is arbitrary safe name (no spaces). Python install should have standardized that ages ago, but since it didn't ...
So, in the general case, EditWithIdleX.py will need to EnumKey under HKCR\Python.File\Shell (guided by the result from QueryInfoKey) and find (with a regex) the one that either loads idlelib or idle.pyw.
Also, people tend to keep 2.7 so in general case it needs to be aware of the version (and probably extract the folder before \pythonw.exe) and bitness (to construct proper MUIVerb text if it's not first/alone). Chances are that people will also start keeping 4.0 soon enough.
People who keep several versions (and even bits) tend to add additional level in registry, like:
[HKEY_CLASSES_ROOT\Python.File\shell\editwithidle]
"MUIVerb"="&Edit with IDLE"
"Subcommands"=""
[HKEY_CLASSES_ROOT\Python.File\shell\editwithidle\Shell]
and then variants from there, like "edit27-32\command", "edit27-64\command", "edit36-32\command", "edit36-64\command", and again the intermediary names are not significant (as long they are locally unique and safe) since they all carry MUIVerb fields. But for searching/enumeration tactics it's a thing that's good to know and handle.
For the extensionManager and idlexMain it would be best is someone who knows "history" pinpoint what is messing with module names and why why does it inject a faux module name instead of copying/generating idlelib.config during the IdleX reg key setup. They contain:
from idlelib.configHandler import idleConf, IdleConfParser which makes them throw when EditWithIdleX.py runs to setup reg keys. But, after that, when R-click is used from Explorer, (idlexlib\launch.py runs), they silently prevent IdleX from running (something probably eats an exception) unless the nonexistent module name is back => the proverbial flip-flopping.
That would be all :-)
Thank you for the changes and information. I wrote the original EditWithIdleX for WinXP and never revisited it. I will need to carefully review and learn from what you wrote.