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: Patch to make PyShell behave more like a Terminal interface #46956
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=Nonecreated_at=<Date2008-04-27.18:02:39.048>labels= ['expert-IDLE', 'type-bug', '3.10']
title='IDLE: Patch to make PyShell behave more like a Terminal interface'updated_at=<Date2020-08-01.20:20:09.331>user='https://github.com/serwy'
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)
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).
serwy commented on May 3, 2008
serwymannequin
MannequinAuthor
More actions
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.
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).
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.
serwy commented on Jun 17, 2008
serwymannequin
MannequinAuthor
More actions
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:
If the cursor is at the end of the line, then up/down navigates the
history.
If the cursor is not at the end of the line, then up/down places the
cursor at the end, so that subsequent up/down navigates the history.
For multi-line inputs:
If the cursor is at the end of the input and the input is in the
history, then up/down navigates the history.
If the cursor is at the end of the input and the input is NOT in the
history, then up will move the cursor up.
If the cursor is at the first line of the input, then up will be ignored.
If the cursor is on the last line of the input, then down will be ignored.
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.
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.
bmiller commented on Mar 11, 2009
bmillermannequin
Mannequin
More actions
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.
The issue of the cursor moving to the left of >>> in the
shell is
separate. See also python/issues-test-cpython#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....
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!
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.
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.
check idle terminal functionality
--> should not show terminal changes from 2704:
up arrows move cursor
typing out of focus has no effect
clicking above the prompt, then typing, does not move cursor to the prompt and begin typing
install Terminal.py in idlelib
apply PyShell.py.patch
click out of focus and type
--> cursor returns to prompt + text appears
backspace
--> backspace deletes text on prompt line
press up arrow
--> cursor does not move up
--> bell sounds as there are no previous commands
enter a few commands, then use up/down keys to navigate history
--> up and down browse through history
There seems to be a bell command in the history as I cycle through commands when I cross from earliest to latest.
SeanWolfe commented on May 12, 2015
SeanWolfemannequin
Mannequin
More actions
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 .
The PyShell patch does two things that I want to consider separately, and carefully, along with other possible solutions to the perceived problems.
Go to end-of-file when entering a letter or number in a read-only text area. In msg110889 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 <tab> 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.
Make <up> and <down> 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 msg68299, make my head hurt. I would rather use Shift-, cntl-, or alt- up/down instead.
The fundamental issue, touched on by Cherniavsky Beni in msg67706, 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 msg66119, I probably was not aware of being able to retrieve statements with Alt-P.
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.
bpo-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.
Activity
serwy commentedon Apr 27, 2008
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)
terryjreedy commentedon May 2, 2008
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).
serwy commentedon May 3, 2008
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:
kbkaiser commentedon May 4, 2008
Thanks for the patch, I'll look at it.
In the future, please send unified diffs (-u), not plain diffs.
cben commentedon Jun 4, 2008
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.
serwy commentedon Jun 17, 2008
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:
history.
cursor at the end, so that subsequent up/down navigates the history.
For multi-line inputs:
history, then up/down navigates the history.
history, then up will move the cursor up.
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.
terryjreedy commentedon Aug 8, 2008
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.
bmiller commentedon Mar 11, 2009
The patch does a great job of scrolling through the history at the current
prompt. This is a great improvement! Thanks.
kbkaiser commentedon Apr 2, 2009
kbkaiser commentedon Apr 2, 2009
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!
terryjreedy commentedon Apr 2, 2009
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.
kbkaiser commentedon Apr 3, 2009
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.
17 remaining items
SeanWolfe commentedon May 12, 2015
Windows 7 patch test successful:
https://bugs.python.org/issue2704
--> should not show terminal changes from 2704:
install Terminal.py in idlelib
apply PyShell.py.patch
click out of focus and type
--> cursor returns to prompt + text appears
backspace
--> backspace deletes text on prompt line
press up arrow
--> cursor does not move up
--> bell sounds as there are no previous commands
enter a few commands, then use up/down keys to navigate history
--> up and down browse through history
There seems to be a bell command in the history as I cycle through commands when I cross from earliest to latest.
SeanWolfe commentedon May 12, 2015
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 .
terryjreedy commentedon May 14, 2015
The PyShell patch does two things that I want to consider separately, and carefully, along with other possible solutions to the perceived problems.
The fixed key-binding for goto-file-end is cntl-end (command-end). I propose adding <tab> 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.
The fundamental issue, touched on by Cherniavsky Beni in msg67706, 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 msg66119, I probably was not aware of being able to retrieve statements with Alt-P.
terryjreedy commentedon May 14, 2015
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.
terryjreedy commentedon Aug 1, 2020
bpo-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.