It would be useful if the right click context menu had the 
usual 'cut/paste/copy' options - as in most other IDEs. 

I regularly lose my selection because IDLE doesn't 
behave the same way as most other editors in this 
regard.

Logged In: YES 
user_id=80475

+0

Control-X, Control-C, and Control-V work fine for me.  

Still, the OP's suggestion is a standard way of doing things.

Logged In: YES 
user_id=1123892

It's a standard way of doing things (and so an ingrained habit 
for at least windoze users) - and also if you're using the 
mouse to make a selection and then change focus to another 
window to paste into it; it's easier to be able to do the whole 
operation with the mouse than change to the keyboard and 
back again.

Logged In: YES 
user_id=149084

This came up on idle-dev, as I remember.

Seems like a reasonable suggestion to me.

Maybe OP could write a patch? All the pertinent code
should be in EditorWindow.py.

1) in file EditorWindow.py 2 editings:

a) remove selection-killer command on popup

    def right_menu_event(self, event):
--      self.text.tag_remove("sel", "1.0", "end")

b) add ability to make separators in popup menu

    def make_rmenu(self):
        rmenu = Menu(self.text, tearoff=0)
        for label, eventname in self.rmenu_specs:
++          if label != "-":
                def command(text=self.text, eventname=eventname):
                    text.event_generate(eventname)
                rmenu.add_command(label=label, command=command)
++          else:
++              rmenu.add_separator()
        self.rmenu = rmenu

2) in PyShell.py extend rmenu_specs

    rmenu_specs = [
++      ("Cut", "<<Cut>>"), 
++      ("Copy", "<<Copy>>"),
++      ("Paste", "<<Paste>>"),
++      ("-", ""),
        ("Set Breakpoint", "<<set-breakpoint-here>>"),
        ("Clear Breakpoint", "<<clear-breakpoint-here>>")
    ]

done...

And now I can't find easy way to next two desired features:
  1) disable cut/copy commands in case no selection (but it is not
exists in main menu too)
  2) display assigned hot keys in popup menu

What do you think about adding a third element for each tuple in
rmenu_specs ? This new element would be a string determining the name of
a function that would be called to define the state of each entry in the
right menu. If None is used in place of a string, then it is assumed
that the entry doesn't require such thing.

Attaching a patch that does that. It also adds cut/copy/paste to the
right menu in IDLE shell.

> 2) display assigned hot keys in popup menu

Is that really necessary ? I've looked for that on some applications I
use most and none of them include hot keys in right menus.

I agree with Guilherme: shortcuts don't need to appear in the context menu.

Guilherme's patch looks pretty good overall, but I have a few remarks:

1) Pasting should be disabled in the Shell window when the cursor is before the I/O mark. (the behavior for cutting is correct)

2) Code relevant to the Shell window should be in PyShell, not in EditorWindow with a getattr(self, 'interp', None) check.

3) Tk.Text.compare can receive names of tags to compare (don't have to do Tk.Text.index('<tag name>'))

So I made these changes. Attached are patches against current trunk (2.x) and py3k branch.

My testing on Windows7 with both 2.7 and 3.1.2 showed this change works well. This should be tested on OSX and Linux since it interacts with the clipboard, which works differently on these platforms.

display assigned hot keys in popup menu is must-have feature, that allow users to teach them while using commands by menu or by context menu. For examples look Delphi IDE

I used taleinat's patch as the start for a patch that works with 3.4.  Lots of code was changed from 2010 to 2012 so I basically hand merged the patch into 3.4.  This patch was tested with Python 3.4.0a0 on both Mac OS X and Linux.  As suggested by taleinat and Guilherme the shortcuts keys are not included in the context menu.

This time I ran make patchcheck on the patch and it corrected a single white space.

I used taleinat's patch as the start for a patch that works with 3.4.  Lots of code was changed from 2010 to 2012 so I basically hand merged the patch into 3.4.  This patch was tested with Python 3.4.0a0 on both Mac OS X and Linux.  As suggested by taleinat and Guilherme the shortcuts keys are not included in the context menu.

I used taleinat's patch as the start for a patch that works with 2.7.  Lots of code was changed from 2010 to 2012 so I basically hand merged the patch into 2.7.  This patch was tested with Python 2.7.3 on both Mac OS X and Linux.  As suggested by taleinat and Guilherme the shortcuts keys are not included in the context menu.

Changed the version to make it clear this issue as a patch for 3.4 and 2.7.

Same patch as before but updated the documentation and help.txt file for IDLE.  This is for Python 2.7.

Same patch as before but updated the documentation and help.txt file for IDLE.  This is for Python 3.4.

New changeset 639dd6e62de4 by Andrew Svetlov in branch '2.7':
Issue #1207589: Add Cut/Copy/Paste items to IDLE right click Context Menu
http://hg.python.org/cpython/rev/639dd6e62de4

New changeset 66643fcf6ee9 by Andrew Svetlov in branch '3.2':
Issue #1207589: Add Cut/Copy/Paste items to IDLE right click Context Menu
http://hg.python.org/cpython/rev/66643fcf6ee9

New changeset 3f3b72ab9d65 by Andrew Svetlov in branch '3.3':
Merge issue #1207589: Add Cut/Copy/Paste items to IDLE right click Context Menu
http://hg.python.org/cpython/rev/3f3b72ab9d65

New changeset e6bf779111a8 by Andrew Svetlov in branch 'default':
Merge issue #1207589: Add Cut/Copy/Paste items to IDLE right click Context Menu
http://hg.python.org/cpython/rev/e6bf779111a8

Committed. Thanks to all.
Keeping in mind idlelib is a bit specific part of stdlib which cannot make backward incompatibility I've committed to 2.7, 3.2, 3.3 and 3.4.

Andrew, this is clearly a new feature, not a bug.  What is your rationale for adding it to the maintenance branches (2.7, 3.2, and 3.3)?

I thought it's desirable feature which cannot produce backward incompatibility problems.
Can revert commits for 2.7-3.3 if needed.

Ned,
  I respectfully disagree that this is not a new feature.  IDLE could always copy/cut/paste from the edit menu and it had a right click menu. All this patch does is add options to right click menu and call the same functions as the edit menu does.  I could be biased because I worked on the patch and I am a new contributor but I think Andrew's logic of commenting the patch makes sense.  Python is a great scripting language but IDLE is really falling behind and it is often the first thing a user sees.  Thanks for your attention in this matter and I will respect any solution you and Amdrew come up with.

The reason for our "no new features" policy is that if a program works with version x.y, it should work for all x versions (modulo failing on an earlier version because of a bug...and conversely if it works on x.y, it should work on all later versions of x, which is why we also sometimes don't fix certain bugs in maintenance releases).

In this case, if I understand correctly, there are no *programs* that can depend on the feature, just humans.  So I think putting this in to bugfix releases is more analogous to the fixes-that-look-like-enhancements we occasionally put into the build infrastructure for Python itself (as opposed to distutils, which is governed by the normal backward compatibility rules).

So, it's a judgment call and other developers might not agree with me, but I think it is OK.

It it not a new library feature that anyone would use in other code. I have been meaning to raise this issue on pydev to see what others think. There are advantages to keeping the *human* interaction with IDLE consistent between releases.

In a strict sense, the patch does break backward compatibility for third-party IDLE extensions that modify the rmenu_specs contents. It is not a "private" value since it lacks an initial underscore in its name. But given how undocumented IDLE is, especially its extension facility, I don't think poses any problems.

(For what it's worth, I'm the developer of IdleX and I already released a trivial workaround for this change. I welcome this improvement to IDLE, especially when it deprecates an existing IdleX extension.)

While keeping UI consistency may be desirable, keeping it crippled is not. Even Window's Notepad has a decent right-click menu.

Ah.  Well, we prefer to err on the side of strictness for backward compatibility, so I think we should treat this as an enhancement, then.

I think it is clear that this is an enhancement.  So then the question is: is there a good reason to make an exception here to the "no new features in maintenance releases" policy? David mentioned some considerations.  I would add testing and documentation.  Testing is a *big* concern with IDLE since IDLE is so dependent on Tk and we know from long experience that there can be differences among the various platform-specific Tk implementations (we currently support at least 4 different Tk varieties) and we have no standard automated tests for IDLE.  So that increases the risk that we could break something in a maintenance release which we try really hard not to do.  On the other hand, there is something to be said about maintaining compatibility as best as possible across IDLE version.

I'm not fundamentally opposed to including this enhancement in maintenance releases.  But I think it is important to recognize that it is an exception to policy and to have this discussion about it.  Personally, I'm +0 on the whole feature - it's not something I would use - so I don't really have a stake in it.  I do have a bit of a stake in the testing part and for that reason I'm -0 on the backports.  I'm glad to see Todd tested on Linux and OS X - presumably someone has tested on Windows.  If the backports remain, the feature should at least be smoke-tested at some point on all four of the branches and with all of the major Tk versions (Windows, X11, OS X Cocoa Tk 8.5, OS X Carbon Tk 8.4).  Since he has the most experience in this area, I'm willing to defer to Roger's judgement call on the impact of this change with regard to IDLE extensions.

On pydev, I explained why I think the bug-enhancement policy does not necessarily apply to IDLE, starting the the fact that IDLE was treated as exceptional and not considered bound to normal policy when it was considered for deletion and ending with the fact that exclusionary dichotomous classification is inherently ambiguous in the absence of specification.

Leaving that aside, the right-click context menu is not mentioned in the brief Library manual chapter on IDLE. It is a GUI matter. I suspect that the docs also do not specify the right-click behavior of the standard interpreter either. 

The apparent external GUI standard, at least on Windows, is that context menus have copy, cut, and paste entries as appropriate. I am pretty sure that this could be found in an MS document entitled something like Human Useability Guidelines. By that standard, it was a bug for those to be missing. I know Apple has interface standards docs also, but I don't know what the standard is.

For instance, Firefox has Cut Copy and Paste within this edit box, with the first two activated when a selection is made. Outside the edit box, only Cut appears, when a selection is active.

I think one could reasonably say that this feature is both a bug fix and an enhancement. After all, all bug fixes are enhancements and all enhancements fix the bug of their absence. We use documented intention to tip the scale one way or the other, but that is completely missing for this feature and mostly missing, except for existence and the common, non-Python-specific meaning of words like 'search box', for everything else.

I guess the schema: keep the current state a while.
Please test context menu for all configurations you have.

If you will have any problem — commits will be reverted.
If anybody will report about backward incompatibility problems — I'll revert changes.

Modifying IDLE extensions is not big deal if somebody need it.

"Leaving that aside, the right-click context menu is not mentioned in the brief Library manual chapter on IDLE."

FTR, as I pointed out on python-dev, this is no longer true.  The IDLE section of the Standard Library documentation, as well as the IDLE help file, were updated by the changes for Issue10405.  The changes committed for this issue (#1207589) further updated those to document this new feature.  See for instance:

http://docs.python.org/2/library/idle.html#edit-context-menu

On IDLE Extensions: The public ecosystem of IDLE extensions is small, and even smaller are those that modify rmenu_specs. Changing it is trivial. However, existing users of the Squeezer extension under 2.7 will experience bugs, like triggering issue13582 on Windows.

It is possible to make the code in make_rmenu backwards compatible. The attached patch against 2.7 (and 3.4) does it.

LGTM

New changeset 3fad938e9d4e by Roger Serwy in branch '2.7':
#1207589: Backwards-compatibility patch for right-click menu in IDLE.
http://hg.python.org/cpython/rev/3fad938e9d4e

New changeset c26ec5897c5a by Roger Serwy in branch '3.3':
#1207589: Backwards-compatibility patch for right-click menu in IDLE.
http://hg.python.org/cpython/rev/c26ec5897c5a

New changeset 5219c1271156 by Roger Serwy in branch 'default':
#1207589: merge with 3.3.
http://hg.python.org/cpython/rev/5219c1271156

Very strange but I noticed the right click menu is not working on Mac OS X.  Before and after Roger's latest backwards_compat.patch.  I must be losing my mind but I thought this was working on OS X. The right click activation I am trying is control-click and I am running 10.8.3.  

Should I file a separate bug report for this issue?

Please do open a separate issue. We'll resolve it there.

No problem I will open a separate issue.  Hopefully it is a mistake on my end and I have something dorked up.