Issue 2704: IDLE: Patch to make PyShell behave more like a Terminal interface (original) (raw)

Created on 2008-04-27 18:02 by roger.serwy, last changed 2022-04-11 14:56 by admin.

Messages (34)

msg65888 - (view)

Author: Roger Serwy (roger.serwy) * (Python committer)

Date: 2008-04-27 18:02

See attached diff file. Patching PyShell.py Version 1.2.1

PyShell ignores letter/number key presses when the cursor is not on the command line. Instead it should redirect any letter/number key presses to the command line. (Changed ModifiedUndoDelegator)

Also, up/down arrow presses should scroll through history when the cursor is on the command line. But when the cursor is not on the command line, the arrow keys should move around the PyShell window. (Added new bindings with conditional logic)

msg66119 - (view)

Author: Terry J. Reedy (terry.reedy) * (Python committer)

Date: 2008-05-02 21:58

I like the two changes: jump to command line and scroll previous command lines without having to search back up through the output. Just don't imitate the Windows terminal too closely with its inability to just select previous output (without Symbol/Edit/Mark).

msg66171 - (view)

Author: Roger Serwy (roger.serwy) * (Python committer)

Date: 2008-05-03 20:32

Hi Terry,

The patch allows you to select previous output if your cursor leaves the command line area. Press the left arrow button at a new command line does this.

Thank you for your feedback!

Terry J. Reedy wrote:

Terry J. Reedy <tjreedy@udel.edu> added the comment:

I like the two changes: jump to command line and scroll previous command lines without having to search back up through the output. Just don't imitate the Windows terminal too closely with its inability to just select previous output (without Symbol/Edit/Mark).


nosy: +tjreedy


Tracker <report@bugs.python.org> <http://bugs.python.org/issue2704>


msg66249 - (view)

Author: Kurt B. Kaiser (kbk) * (Python committer)

Date: 2008-05-04 22:22

Thanks for the patch, I'll look at it.

In the future, please send unified diffs (-u), not plain diffs.

msg67706 - (view)

Author: Cherniavsky Beni (cben) *

Date: 2008-06-04 22:54

The patch logic is very simple: inside the command area Up/Down move through history. But what about multi-line editing? Wouldn't this interfere when you just want to move between lines in a multi-line command (e.g. a long def)? I'm afraid the conditional logic needs more refining to be useful.

msg68299 - (view)

Author: Roger Serwy (roger.serwy) * (Python committer)

Date: 2008-06-17 00:56

I rewrote the patch to better handle multi-line input. In rewriting the patch I realized that there can be many different ways to handle up/down key presses while the cursor is in the input region. Here is the behavior of this patch:

For single line inputs:

For multi-line inputs:

If the cursor leaves the input area, either by pressing left at the start of the input area, or by clicking elsewhere in the text box, the up/down keys behave as they do now.

If the cursor is outside the input area and a character key is pressed, the cursor is placed and the end of the input, and the character is placed there.

Also, this patch fixes a subtle cursor placement bug when dealing with multi-line inputs. When navigating from line 2 to line 1 of a multi-line, the cursor can end up in the ">>>" prompt. This is fixed so that the cursor stays in the input area.

msg70911 - (view)

Author: Terry J. Reedy (terry.reedy) * (Python committer)

Date: 2008-08-08 21:04

On windows: type

zomeinput Press home key. In command window (terminal interface), cursor goes to just before z, where one would want. In IDLE (2.5.2, 3.0b2), it goes to beginning of line. If current patch does not fix this (there is no mention), would it be easy to add?

I would expect so because the current page up places the cursor 4 chars to the right of the margin (if there is text not visible above the window to jump to and if there is text on the line jumped to). So PageUp PageDn will sometimes simulate the desired Home behavior.

msg83478 - (view)

Author: Brad Miller (bmiller)

Date: 2009-03-11 20:04

I hand applied the patch because I hoped it would fix the problem of the cursor going all the way to the left of the >>> in the Python shell when you press home or ctrl-a. The patch as it is does not solve this problem on the Mac. I've uploaded the patch as a unified diff to make it easier for others who might want to give it a try.

The patch does a great job of scrolling through the history at the current prompt. This is a great improvement! Thanks.

msg85218 - (view)

Author: Kurt B. Kaiser (kbk) * (Python committer)

Date: 2009-04-02 16:14

The issue of the cursor moving to the left of >>> in the shell is separate. See also #3851. The current action of the home key, released in 2.6, is from patch 1196903. @tjreedy, if in 2.6 you type >>> syzygy and hit home, the cursor moves to the left of the 's'. A second 'home' moves it to the left margin.
Subsequent presses toggle the cursor between those two position.
While the action in the shell could be special cased, I consider this to be cosmetic - and not only that, but moving to the left border is useful when you want to mark a shell region for copy/ paste. So "won't fix" is my response to that 'complaint'. Now back to the subject of this patch....

msg85219 - (view)

Author: Kurt B. Kaiser (kbk) * (Python committer)

Date: 2009-04-02 16:16

Why doesn't someone fix this comment widget?? It was like this on SF, too. Guess I've got to dive in at some point...second guessing the wrapping drives me nuts!

msg85237 - (view)

Author: Terry J. Reedy (terry.reedy) * (Python committer)

Date: 2009-04-02 18:36

Kurt, do not type hard returns except at the end of code lines and paragraphs.

As I said in my previous comment, the HOME key works as I said both in 2.5 AND in 3.0 (and still in 3.0.1). If it was fixed in 2.6, fine, but that fix was either not forward ported to 3.0 or was otherwise disabled.

msg85319 - (view)

Author: Kurt B. Kaiser (kbk) * (Python committer)

Date: 2009-04-03 19:35

As far as typing in the comment widget goes - it works fine if you don't add CR at the end of the lines until you go back and edit it by inserting some text. Then the faulty wordwrapping kicks in, and it has to be fixed by removing all the extra spaces and CR by hand. The only way around it that I've found is to use hard CR.
But then you have to second guess the right margin. You'll notice that if you undo the wrapping it did on my comment, that the lines are shorter than in your comments! This paragraph was entered w/o returns. It gets screwed as soon as I click outside the widget. And the screwing depends on the width of my browser window, because that affect the width of the text entry widget.

Rev 62545 to 2.6 was forward ported to 3.0 on 4May, r62716. I'm using py3k HEAD and it works the same as 2.6: pressing Home toggles beween the left margin and the start of the code text.

msg85332 - (view)

Author: Terry J. Reedy (terry.reedy) * (Python committer)

Date: 2009-04-03 21:00

As you said, the Home key issue is #3851, which makes is clearer that it appears to be Windows only. I should have specified that here.

msg86627 - (view)

Author: Daniel Diniz (ajaksu2) * (Python triager)

Date: 2009-04-26 22:46

Kurt: regarding line wrapping, can you report your browser and OS at http://psf.upfronthosting.co.za/roundup/meta/issue277 ?

msg101182 - (view)

Author: Cherniavsky Beni (cben) *

Date: 2010-03-16 19:50

History access by Up/Down is important because it makes IDLE history much more discoverable. Most users instinctively expect Up/Down to work; moving back through the text of the session is nice but they probably won't guess that you can press Enter to reuse old commands; and it's not an efficient way to access history anyway.

The problem is increased by the fact that Alt+P/N don't appear anywhere in the menus, so a user will never discover them!

msg101735 - (view)

Author: Roger Serwy (roger.serwy) * (Python committer)

Date: 2010-03-25 23:23

Rather than change the core code of IDLE, I've attached an extension to achieve terminal-like behavior. It provides a toggle to enable/disable. However, this extension as-is only works on the 2.x series, although it can be modified slightly to work on 3.x.

msg110888 - (view)

Author: Tal Einat (taleinat) * (Python committer)

Date: 2010-07-20 11:51

IDLE should be accessible and easy to use for beginners who have never used a command line. Therefore I don't think up/down should scroll through the history by default. Since IDLE looks like a text editor (even the shell window) it is more intuitive that the arrows should move the cursor around the window.

Note that a user can configure up/down to scroll through the history quite easily using the configuration dialog.

I agree that as it stands it is hard to discover how to scroll through the history, and that Return can be used to bring previous code into the current command line. I think we can find a better way to make these features known to new users, without making the interface less intuitive.

For example, we could have a "Welcome to IDLE!" screen that appears the first time IDLE is run by a user, which outlines a few basic features such as these. This should of course be complemented by better documentation, including a section on various commands (a separate issue).

msg110889 - (view)

Author: Tal Einat (taleinat) * (Python committer)

Date: 2010-07-20 11:57

Regarding passing on letter/number key-presses to the command line, I'm -0 on this. Note that not only letter/number keys should be passed on.

I've often found myself wanting to type in the command line after looking at previous code, to see that my key presses are being ignored, and having to Ctrl+End to return the cursor to the command line.

However, if I was scrolling through the history and by accident hist a letter or number, having the cursor jump to the command line and the window scroll back to the end would be annoying. Personally, I would prefer avoiding this and having to use Ctrl+End to return to the command line.

msg182743 - (view)

Author: Ramchandra Apte (Ramchandra Apte) *

Date: 2013-02-23 13:37

+1000

msg185026 - (view)

Author: Todd Rovito (Todd.Rovito) *

Date: 2013-03-23 03:09

Made minor modifications to Roger's Terminal.py to get the extension to work with Python 3.4. This is an excellent extension as a user can toggle it on/off from the Options menu. The up/down arrow keys now allow a user to scroll through history but the meta-n meta-p keys still work offering the best of both worlds. If a user wants to scroll around the screen with the arrow keys simply turn off the extension from the option bar and start moving the cursor with the arrow keys. Excellent work Roger!!!!!

-Changed the original variable from enabled to enable to match other extensions -Tested it on Mac OS X with 3.4 and it works PERFECT! -Added a small if statement to pull in the right tkinter import based on sys.version

msg185027 - (view)

Author: Todd Rovito (Todd.Rovito) *

Date: 2013-03-23 04:21

I tested the patch on Linux CentOS 6.x and it seems to work. Now if we could only get somebody to test on Windows?

msg185091 - (view)

Author: Roger Serwy (roger.serwy) * (Python committer)

Date: 2013-03-23 21:19

Thanks, Todd, for reviewing and testing the extension!

The Terminal.py extension patch provided here is outdated. There have been some minor tweaks and bug fixes that can be found in the IdleX project which works under 2.x and 3.x with the same code. (For example, I removed an unnecessary reference to the history object in the latest version so that I could better support IPython). I know that the IdleX version works under Linux, Windows, and MacOSX.

Unfortunately, on MacOSX, the "Options" menu may not be present which breaks the loading of Terminal.py. IdleX re-introduces the Options menu on MacOSX if it is missing. I will create a separate issue for the Options menu.

msg185107 - (view)

Author: Todd Rovito (Todd.Rovito) *

Date: 2013-03-24 02:03

No problem Roger. I have attached a new patch for documentation updates to both the IDLE help.txt file and idle.rst for the Terminal extension. Would it be helpful if I did a diff on the idleX Terminal.py with your original patch? In addition to doing the patch I can also perform some more testing. Please let me know what I can do to support you getting this patch committed. Thanks.

msg185109 - (view)

Author: Todd Rovito (Todd.Rovito) *

Date: 2013-03-24 02:42

Roger, I took Terminal.py and copied it into Lib/idlelib for the 3.4 branch. The extension started just fine but when I toggle it off under the options menu the arrow keys still go through history. Basically on my Mac I see no difference between the extension being turned on/off when I use Terminal.py from idle-X version 1.11.2. I am not sure why when I toggle the extension off I can't move around the shell window with my cursor keys like the original patch allowed me to do. Hopefully this helps. Thanks.

msg185114 - (view)

Author: Todd Rovito (Todd.Rovito) *

Date: 2013-03-24 05:11

After looking at the code some more I realized that I didn't have my configuration file configured correctly. The toggle was not working because I left this out of my config-extensions.def file: [Terminal_cfgBindings] terminal-toggle=

Now it is working great without that variable the toggling does not work.

msg188703 - (view)

Author: Phil Webster (philwebster) *

Date: 2013-05-08 06:38

After reading about beginners having difficulty with IDLE's terminal behavior, I wrote a (very) simple patch to disable left clicking in the text area. I realize that this doesn't solve the problem completely (and the fact that there is already a patch here), but I wanted to become familiar with the contribution process. Thanks for your patience with me!

msg188754 - (view)

Author: Roger Serwy (roger.serwy) * (Python committer)

Date: 2013-05-09 06:28

Welcome Phil! Your patch looks good and applied cleanly to the default branch and behaves as you specified. Your submission mechanics are good!

You might want to look into signing a contributor's agreement: http://docs.python.org/devguide/coredev.html#sign-a-contributor-agreement

msg212780 - (view)

Author: Sean Wolfe (Sean.Wolfe)

Date: 2014-03-05 23:40

I just tried this out on osx 10.9.0 and python 2.7.5 :

This is much better! A big irritation gone for me and makes things much easier for beginners IMO -- one less thing to get surprised by.

msg212781 - (view)

Author: Sean Wolfe (Sean.Wolfe)

Date: 2014-03-05 23:42

installation steps for me:

This was in the osx 10.9 system python directories, so there was some sudo-ing involved.

msg242991 - (view)

Author: Sean Wolfe (Sean.Wolfe)

Date: 2015-05-12 19:11

Windows 7 patch test successful:

https://bugs.python.org/issue2704

There seems to be a bell command in the history as I cycle through commands when I cross from earliest to latest.

msg242994 - (view)

Author: Sean Wolfe (Sean.Wolfe)

Date: 2015-05-12 19:15

successfully tested on Linux in 2014

Hello folks, FYI I also installed this patch on Lubuntu linux in 2014 on a series of computers at a lab where I mentor. I don't have the documentation for those specific tests, but I did follow the outline above, and it was done.

So, IMO we can call this tested on W7, Linux and OSX 10.9.3, for Python 2.7 .

msg243140 - (view)

Author: Terry J. Reedy (terry.reedy) * (Python committer)

Date: 2015-05-14 02:06

The PyShell patch does two things that I want to consider separately, and carefully, along with other possible solutions to the perceived problems.

  1. Go to end-of-file when entering a letter or number in a read-only text area. In Tal says "Note that not only letter/number keys should be passed on." I see the point, but expanding the set seems to me a complication and a move in the wrong direction. Doing nothing, or maybe beeping, is a normal response to entry in a read-only area. Regardless of what I wrote before, I am not completely comfortable with adding magical behavior.

The fixed key-binding for goto-file-end is cntl-end (command-end). I propose adding as a synonym. Currently, it sometimes opens a completion box even in read-only areas, where it is useless and annoying. This should be changed anyway, and having it cause the cursor to jump to me seems to fit with its indent behavior.

  1. Make and do double duty to both traverse statements in the history and lines within the current statement. However, the complicated rules to juggle two roles, in , make my head hurt. I would rather use Shift-, cntl-, or alt- up/down instead.

The fundamental issue, touched on by Cherniavsky Beni in , is that Python is not a command-line language. It is a statement language. It does not fit well in a command-line terminal where history consists of lines rather than statements. PyShell is a statement terminal designed to fit Python, not a line terminal.

I appreciate this much better than 7 years ago. When I wrote , I probably was not aware of being able to retrieve statements with Alt-P.

msg243141 - (view)

Author: Terry J. Reedy (terry.reedy) * (Python committer)

Date: 2015-05-14 02:14

The changes I proposed would not have to be extensions, as they are basically non-conflicting alternate keybindings, though the tab effect would have to be conditional. I will experiment with using prefix-up/down in one of my installed pythons.

msg374668 - (view)

Author: Terry J. Reedy (terry.reedy) * (Python committer)

Date: 2020-08-01 20:20

#41075 is specifically about history navigation. I tried Shift/Control/Alt - Up/Down and none worked. Rebinding just Up/Down did (in Shell, with Editor unchanged). But not having up/down work to move between lines in the Shell multiline statement entry area is not acceptable to me. Two additional idea from the new issue: a) Add history commands to context menu to make them more discoverable; b) When statement has SyntaxError, put Error message in box and let user edit bad code directly, as in Editor.

History

Date

User

Action

Args

2022-04-11 14:56:33

admin

set

github: 46956

2020-08-01 20:20:09

terry.reedy

set

messages: +

2020-06-08 00:34:50

terry.reedy

set

versions: + Python 3.10, - Python 3.6, Python 3.7

2019-08-14 06:51:52

terry.reedy

link

issue37847 superseder

2018-06-18 08:44:55

terry.reedy

link

issue33893 superseder

2017-06-30 00:07:58

terry.reedy

set

assignee: kbk -> terry.reedy
stage: needs patch -> patch review
versions: + Python 3.6, Python 3.7, - Python 2.7, Python 3.4, Python 3.5

2016-02-13 12:00:55

THRlWiTi

set

nosy: + THRlWiTi

2015-09-18 16:45:25

markroseman

set

nosy: + markroseman

2015-05-14 02:14:56

terry.reedy

set

messages: +

2015-05-14 02:06:12

terry.reedy

set

stage: patch review -> needs patch
messages: +
versions: + Python 3.5, - Python 3.3

2015-05-12 19:15:43

Sean.Wolfe

set

messages: +

2015-05-12 19:11:47

Sean.Wolfe

set

messages: +

2015-01-07 06:40:58

Al.Sweigart

set

nosy: + Al.Sweigart

2014-03-05 23:42:53

Sean.Wolfe

set

messages: +

2014-03-05 23:40:08

Sean.Wolfe

set

nosy: + Sean.Wolfe
messages: +

2014-02-04 12:03:07

taleinat

set

nosy: - taleinat

2013-05-09 06:28:29

roger.serwy

set

messages: +

2013-05-08 06:38:29

philwebster

set

files: + Issue2704.patch
nosy: + philwebster
messages: +

2013-04-29 16:27:08

Sarah

set

nosy: + Sarah

2013-03-24 05:11:00

Todd.Rovito

set

messages: +

2013-03-24 02:42:37

Todd.Rovito

set

messages: +

2013-03-24 02:03:39

Todd.Rovito

set

files: + 2704IDLEMakeShellBehaveLikeTerminaliDocumentationUpdateFor3dot4.patch

messages: +

2013-03-23 21:19:55

roger.serwy

set

messages: +

2013-03-23 04:21:47

Todd.Rovito

set

messages: +

2013-03-23 03:09:35

Todd.Rovito

set

files: + 2704IDLEMakeShellBehaveLikeTerminalFor3dot4.patch

messages: +

2013-03-22 20:17:02

Todd.Rovito

set

nosy: + Todd.Rovito

2013-02-23 13:37:01

Ramchandra Apte

set

nosy: + Ramchandra Apte
messages: +

2013-02-23 03:16:54

terry.reedy

set

versions: + Python 3.3, Python 3.4, - Python 3.1, Python 3.2

2010-07-20 11:57:04

taleinat

set

messages: +

2010-07-20 11:51:02

taleinat

set

nosy: + taleinat
messages: +

2010-07-19 21:23:36

BreamoreBoy

set

versions: + Python 2.7, Python 3.2, - Python 2.6

2010-03-25 23:23:04

roger.serwy

set

files: + Terminal.py

messages: +

2010-03-16 19:50:44

cben

set

messages: +

2009-04-26 22:46:50

ajaksu2

set

nosy: + ajaksu2, gpolo

messages: +
stage: patch review

2009-04-03 21:00:30

terry.reedy

set

messages: +

2009-04-03 19:35:24

kbk

set

messages: +

2009-04-02 18:36:47

terry.reedy

set

messages: +

2009-04-02 16:16:30

kbk

set

messages: +

2009-04-02 16:14:04

kbk

set

priority: normal

messages: +
versions: + Python 3.1

2009-03-11 20:04:58

bmiller

set

files: + PyShell.patch
nosy: + bmiller
messages: +

2008-08-08 21:04:19

terry.reedy

set

messages: +

2008-06-17 00:56:58

roger.serwy

set

files: + PyShell.py.patch
messages: +

2008-06-04 22:54:05

cben

set

nosy: + cben
messages: +

2008-05-22 16:14:50

kbk

set

keywords: + patch

2008-05-04 22:22:19

kbk

set

assignee: kbk
messages: +
nosy: + kbk
versions: + Python 2.6, - Python 2.5

2008-05-03 20:32:57

roger.serwy

set

messages: +

2008-05-02 21:58:46

terry.reedy

set

nosy: + terry.reedy
messages: +

2008-04-27 18:02:39

roger.serwy

create