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).

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>
> __________________________________
>
>

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

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

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.

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.

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 #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.

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.

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

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!

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.

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).

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.