classification
Title: IDLE: Patch to make PyShell behave more like a Terminal interface
Type: behavior
Components: IDLE Versions: Python 2.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: kbk Nosy List: cben, kbk, serwy, tjreedy
Priority: Keywords: patch

Created on 2008-04-27 18:02 by serwy, last changed 2008-06-17 00:56 by serwy.

Files
File name Uploaded Description Edit Remove
patch_PyShell.py serwy, 2008-04-27 18:02 improved PyShell.py code patch
PyShell.py.patch serwy, 2008-06-17 00:56 patch to PyShell.py
Messages
msg65888 (view) Author: Roger Serwy (serwy) 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 (tjreedy) 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 (serwy) 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!

- RDS

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) 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 (serwy) 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:
* 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.
History
Date User Action Args
2008-06-17 00:56:58serwysetfiles: + PyShell.py.patch
messages: + msg68299
2008-06-04 22:54:05cbensetnosy: + cben
messages: + msg67706
2008-05-22 16:14:50kbksetkeywords: + patch
2008-05-04 22:22:19kbksetassignee: kbk
messages: + msg66249
nosy: + kbk
versions: + Python 2.6, - Python 2.5
2008-05-03 20:32:57serwysetmessages: + msg66171
2008-05-02 21:58:46tjreedysetnosy: + tjreedy
messages: + msg66119
2008-04-27 18:02:39serwycreate