"Edit with IDLE" does not work for shortcuts

[5b7e7c7c-c959-4b62-9481-abf90ac1fead]

BPO	25125
Nosy	@terryjreedy, @pfmoore, @tjguk, @zware, @eryksun, @zooba

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = created_at = labels = ['invalid', 'expert-IDLE', 'type-feature', 'expert-installation', 'OS-windows'] title = '"Edit with IDLE" does not work for shortcuts' updated_at = user = 'https://bugs.python.org/thijsvandien' ``` bugs.python.org fields: ```python activity = actor = 'terry.reedy' assignee = 'none' closed = True closed_date = closer = 'terry.reedy' components = ['IDLE', 'Installation', 'Windows'] creation = creator = 'thijsvandien' dependencies = [] files = [] hgrepos = [] issue_num = 25125 keywords = [] message_count = 16.0 messages = ['250759', '251361', '251626', '251637', '251662', '251779', '251787', '251789', '251794', '251892', '252063', '252072', '252090', '252094', '252833', '296674'] nosy_count = 7.0 nosy_names = ['terry.reedy', 'paul.moore', 'tim.golden', 'zach.ware', 'eryksun', 'steve.dower', 'thijsvandien'] pr_nums = [] priority = 'normal' resolution = 'not a bug' stage = 'resolved' status = 'closed' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue25125' versions = ['Python 3.5'] ```

[5b7e7c7c-c959-4b62-9481-abf90ac1fead]

Right clicking a Python file shows "Edit with IDLE" in the context menu, then offering a next menu where one can choose which particular version of IDLE should be used. This works fine. Whenever a shortcut is created to a Python file, the same context menu is shown, but clicking for example "Edit with IDLE 3.5 (32-bit)" does not seem to do anything. This is probably related to a change in the command used to launch IDLE with the file to be edited.

Tested on a fresh install of Windows 7 SP1 X86 and AMD64, with Python 3.5.0 X86.

[zooba]

Can you try executing the following command (fix the paths as necessary, but leave all the quotes where they are):

"C:\Program Files (x86)\Python 3.5\python.exe" -m idlelib "C:\test.py"

That's what should be launched by the menu, with a minor change to use python.exe instead of pythonw.exe to show up any errors you are hitting.

I couldn't reproduce the issue on Windows 10, but when I'm back at work I'll try with some other OS versions.

[5b7e7c7c-c959-4b62-9481-abf90ac1fead]

That works fine, but then again the ticket only concerns the context menu of _shortcuts_ to Python files. Opening Python files directly, either via "Edit with IDLE" in context menu or directly via the CLI, has worked from the beginning.

[zooba]

Ah, I misread that part. Will have to look deeper, but I'm not actually sure that shortcuts are supposed to support the same operations (though if it shows up, I guess it should work).

[eryksun]

Ah, I misread that part. Will have to look deeper, but I'm not actually sure that shortcuts are supposed to support the same operations (though if it shows up, I guess it should work).

A LNK shortcut should support the same commands (e.g. open, edit) as its target. This works for me in Windows 10.

BTW, I don't see how to ShellExecute a subcommand documented on MSDN. One way is to just pass the subkey path as the 'verb', e.g. r"editwithidle\shell\edit35". Probably it's just passed along to RegOpenKeyEx as the subkey, so this shouldn't be used in practice. Could the installer create a simple "edit" command? It doesn't have to be smart about it. Just overwrite the current value, and let a per-user install take precedence.

[zooba]

Creating a "dumb" item was discussed and rejected.

I don't see how passing the subkey is an issue if it works. The name of the verb is considered public API surface, so we can't easily change it anyway.

What may be the issue is the use of "%L", which I recall being told I should use at some point but I don't remember the exact reason. It may be that links are not resolved for %L while using another character (I don't believe %1 is necessarily correct here either, but maybe with %* it's redundant anyway).

[eryksun]

I don't believe %1 is necessarily correct here either, but maybe with %* it's redundant anyway

%0, %1, or %L is lpFile. On older systems "%L" guarantees using the long filename, but this is pointless nowadays. %* (i.e. %2 through %9) is lpParameters, which is unusual to have in an edit command. Here's the edit command for .bat files:

C:\>reg query hklm\software\classes\batfile\shell\edit\command

HKEY_LOCAL_MACHINE\software\classes\batfile\shell\edit\command
    (Default)    REG_EXPAND_SZ    %SystemRoot%\System32\NOTEPAD.EXE %1

It seems using quotes around "%1" is optional.

[zooba]

Does notepad handle clicking "edit" on a shortcut to a batch file? Maybe subcommands don't have exactly the same semantics as regular verbs...

[eryksun]

Does notepad handle clicking "edit" on a shortcut to a batch file? Maybe subcommands don't have exactly the same semantics as regular verbs...

In Windows 7 SP1 a regular verb works fine from a shortcut, but apparently not a subcommand. OTOH, Windows 10 seems to have no problem with this.

I just tested the following subcommand for editing .bat files with notepad:

reg add HKCU\Software\Classes\batfile\shell\editother\shell\editwithnotepad\command
reg add HKCU\Software\Classes\batfile\shell\editother /v MUIVerb /d "Edit Other"
reg add HKCU\Software\Classes\batfile\shell\editother /v Subcommands
reg add HKCU\Software\Classes\batfile\shell\editother\shell\editwithnotepad /v MUIVerb /d "Edit With Notepad"
reg add HKCU\Software\Classes\batfile\shell\editother\shell\editwithnotepad\command /ve /d "C:\Windows\notepad.exe %1"

When accessed from the file itself, this works fine in both Windows 7 SP1 and Windows 10 RTM. When accessed from a shortcut, the command works in Windows 10 but does nothing in Windows 7. This independently confirms the issue reported by Thijs as a Windows 7 bug/limitation.

[5b7e7c7c-c959-4b62-9481-abf90ac1fead]

If this turns out to be a Windows problem, I'd insist not to close it as such but to find away around that. After all, in Python 3.4 there was no subcommand, and all was fine. Do we really need that second level menu? I found it to be less user-friendly as well. How many users want to make a conscious choice between editing in the 32-bit version of IDLE or in the 64-bit version, when both are installed? Does it make any difference at all? Would it matter to add both at top level context menu options, without grouping, considering that probably most users will have only one install anyway?

[zooba]

Terry (nosied) made the request for the context menu in bpo-23546, so if you want it removed you'll need to convince him.

Personally I prefer the context menu, but I typically replace the default file association with one that's better for me anyway so I'm not really bothered either way.

[terryjreedy]

In bpo-23546, I requested a separate 'Edit with IDLE x.y' (I mis-said 'Open') on the context menu for each installed version. I said I would be OK with one 'Edit with IDLE' entry and a submenu, as proposed by someone else. I agree that this will be better in the long run. In the meanwhile, I have 'Edit with IDLE' which happens to be connected to 3.4 and 'Edit with IDLE >' with a submenu with 3.5, and no option to edit with 2.7.

Thijs: The editor is basically the same in the most recent 2.7, 3.4, and 3.5 versions. So it does not matter much which Python version is used to *edit. But it does matter which Python version is used to *run the file with F5. And there are bug fixes in the next 3.4 version that will make editing easier for some people. And there will be even more changes coming in future 2.7 and 3.5 releases.

Perhaps the submenu should give the full x.y.z release number, as Idle can have new or changed features in micro releases.

[5b7e7c7c-c959-4b62-9481-abf90ac1fead]

Terry, I'll write here not to open the old ticket (yet). I'd argue listing all IDLE's under "Open with" is still the best option, rather than yet another menu option. First of all, there is nothing conceptually different about opening the file with IDLE vs. editing it with IDLE; .txt-files open with Notepad, .ppt-files open with Powerpoint, et cetera, and the later offers both editing and "running" as well. Second, it will probably solve this issue with shortcuts because I expect "Open with" not to have the same issue as our own submenu. If we do keep the direct "Edit with IDLE" option as well, it should be quick and direct. Perhaps it would be best just to revert to the old behavior. Otherwise, we can always use the latest available IDLE and improve IDLE to offer an option to choose which version of Python to run with. A next logical step would then be to make it respect the shebang if present, and make it the default version to run with.

[terryjreedy]

Putting them under the current 'Open with >' would also be alright. (It currently lists Notepad, Wordpad, and Py launcher for Windows (console), which I presume means run with default for Py. What I was requesting is that the version be included with the entry wherever it is put. The technical details of the different choices are not my concern.

[zooba]

Because of the way Open With works, we can't do this unless we start building an EXE to launch IDLE (Windows automatically picks up most of the details from the target executable, so it will show as "pythonw" if we do it without the launcher).

Unassigning myself, as there doesn't seem to be anything to "do" right now. If consensus on moving all the versioned menus to the top level context menu is reached (possibly on the IDLE mailing list), it can be re-raised here. I personally don't consider a limitation of Windows 7 wrt shortcuts to be a compelling enough reason to change away from the submenu.

[terryjreedy]

This is not an IDLE code issue, but an installation issue, and I think one main entry with a submenu is proper. I just tried clicking on '3.5.3' and '3.6.2' and both opened an editor for a .py file with the corresponding version.