You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
IDLE right click outside of any selection should clear it #84066
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:
assignee='https://github.com/terryjreedy'closed_at=<Date2020-05-29.23:31:23.218>created_at=<Date2020-03-07.05:08:09.444>labels= ['type-bug', '3.8', '3.9', '3.10', 'expert-IDLE', '3.7']
title='IDLE right click outside of any selection should clear it'updated_at=<Date2020-05-29.23:31:23.216>user='https://github.com/terryjreedy'
In text editors, right click commonly brings up a context menu, often including Cut, Copy, Paste, and Delete, with inapplicable entries grayed out. There are at least 2 'standard' behaviors (at least on Windows) with respect to the cursor and selections.
0 (Examples: Windows Notepad and Firefox entry box). The cursor stays where it is and a selection stays selected, even if one has scrolled the cursor and possible selection off the screen with mousewheel or scrollbar. Paste inserts at the possibly hidden cursor, deleting any possibly hidden selection. The view jumps back to the cursor after Paste but not after Copy and Close (Esc).
1 (Examples: Windows Notepad++ and Libre Office). The cursor jumps to the spot of the click, the same as with a left click. Any selection, possibly not visible, is unselected, the same as with a left click. Exception: a right click within an exception leaves the selection and cursor (at one of the ends) alone.
IDLE follows a bit of each pattern and neither. Right click always moves the cursor, even within a selection, but never clears a selection. I believe that this is an accident of history. Originally, context menus only had 'Go to file/line' in Shell and grep output and 'Set/Clear Breakpoint' in editors. There was no reason to touch a selection even if the cursor was moved. Cut/Copy/Paste were added in 2012 because they are standard.
To really be standard, right click should consistently act like left click and unselect. This prevents accidental deletion. This would also be consistent with making 'Go to line' act the same.
Also, right click within a selection should not move the cursor.
Restore not clearing the selection when click within it. See Exception in 1 above. Users need to continue to see what will be copied or cut (which also happens with paste).
The breakpoint toggle and goto file/line options on the context menu need the line number of the click. If the cursor is not moved, another alternative is needed.
Activity
terryjreedy commentedon Mar 7, 2020
In text editors, right click commonly brings up a context menu, often including Cut, Copy, Paste, and Delete, with inapplicable entries grayed out. There are at least 2 'standard' behaviors (at least on Windows) with respect to the cursor and selections.
0 (Examples: Windows Notepad and Firefox entry box). The cursor stays where it is and a selection stays selected, even if one has scrolled the cursor and possible selection off the screen with mousewheel or scrollbar. Paste inserts at the possibly hidden cursor, deleting any possibly hidden selection. The view jumps back to the cursor after Paste but not after Copy and Close (Esc).
1 (Examples: Windows Notepad++ and Libre Office). The cursor jumps to the spot of the click, the same as with a left click. Any selection, possibly not visible, is unselected, the same as with a left click. Exception: a right click within an exception leaves the selection and cursor (at one of the ends) alone.
IDLE follows a bit of each pattern and neither. Right click always moves the cursor, even within a selection, but never clears a selection. I believe that this is an accident of history. Originally, context menus only had 'Go to file/line' in Shell and grep output and 'Set/Clear Breakpoint' in editors. There was no reason to touch a selection even if the cursor was moved. Cut/Copy/Paste were added in 2012 because they are standard.
To really be standard, right click should consistently act like left click and unselect. This prevents accidental deletion. This would also be consistent with making 'Go to line' act the same.
Also, right click within a selection should not move the cursor.
terryjreedy commentedon Mar 7, 2020
Spinoff from bpo-39852. At least the selection clear code added there should be pulled into a module level function and tested.
terryjreedy commentedon Mar 7, 2020
(Mozilla) Thunderbird, unlike (Mozilla) Firefox, has move/clear right clicks.
7 remaining items
terryjreedy commentedon Mar 12, 2020
Restore not clearing the selection when click within it. See Exception in 1 above. Users need to continue to see what will be copied or cut (which also happens with paste).
The breakpoint toggle and goto file/line options on the context menu need the line number of the click. If the cursor is not moved, another alternative is needed.
[-]IDLE right click should clear any selection[/-][+]IDLE right click outside of any selection should clear it[/+][-]IDLE right click should clear any selection[/-][+]IDLE right click outside of any selection should clear it[/+]terryjreedy commentedon May 29, 2020
New changeset 97e4e0f by Terry Jan Reedy in branch 'master':
bpo-39885: Make IDLE context menu cut and copy work again (GH-18951)
97e4e0f
miss-islington commentedon May 29, 2020
New changeset 80b6a05 by Miss Islington (bot) in branch '3.7':
bpo-39885: Make IDLE context menu cut and copy work again (GH-18951)
80b6a05
miss-islington commentedon May 29, 2020
New changeset 3dcccd1 by Miss Islington (bot) in branch '3.8':
bpo-39885: Make IDLE context menu cut and copy work again (GH-18951)
3dcccd1
miss-islington commentedon May 29, 2020
New changeset 9f3f70f by Miss Islington (bot) in branch '3.9':
bpo-39885: Make IDLE context menu cut and copy work again (GH-18951)
9f3f70f