Skip to content

IDLE: Patch to make PyShell behave more like a Terminal interface #46956

Open

Description

@serwy
mannequin
BPO 2704
Nosy @terryjreedy, @kbkaiser, @cben, @devdanzin, @serwy, @roseman, @rovitotv, @SarahPythonista
Files
  • patch_PyShell.py: improved PyShell.py code patch
  • PyShell.py.patch: patch to PyShell.py
  • PyShell.patch: unified diff version of patch_PyShell.py
  • Terminal.py: Extension for Terminal Mode
  • 2704IDLEMakeShellBehaveLikeTerminalFor3dot4.patch
  • 2704IDLEMakeShellBehaveLikeTerminaliDocumentationUpdateFor3dot4.patch
  • Issue2704.patch: Left click disabled in terminal area
  • 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 = None
    created_at = <Date 2008-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 = <Date 2020-08-01.20:20:09.331>
    user = 'https://github.com/serwy'

    bugs.python.org fields:

    activity = <Date 2020-08-01.20:20:09.331>
    actor = 'terry.reedy'
    assignee = 'terry.reedy'
    closed = False
    closed_date = None
    closer = None
    components = ['IDLE']
    creation = <Date 2008-04-27.18:02:39.048>
    creator = 'roger.serwy'
    dependencies = []
    files = ['10124', '10641', '13306', '16661', '29551', '29557', '30173']
    hgrepos = []
    issue_num = 2704
    keywords = ['patch']
    message_count = 34.0
    messages = ['65888', '66119', '66171', '66249', '67706', '68299', '70911', '83478', '85218', '85219', '85237', '85319', '85332', '86627', '101182', '101735', '110888', '110889', '182743', '185026', '185027', '185091', '185107', '185109', '185114', '188703', '188754', '212780', '212781', '242991', '242994', '243140', '243141', '374668']
    nosy_count = 15.0
    nosy_names = ['terry.reedy', 'kbk', 'cben', 'ajaksu2', 'gpolo', 'bmiller', 'roger.serwy', 'markroseman', 'THRlWiTi', 'Todd.Rovito', 'Ramchandra Apte', 'Al.Sweigart', 'Sean.Wolfe', 'Sarah', 'philwebster']
    pr_nums = []
    priority = 'normal'
    resolution = None
    stage = 'patch review'
    status = 'open'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue2704'
    versions = ['Python 3.10']

    Activity

    1. serwy commented on Apr 27, 2008

      serwymannequin
      MannequinAuthor

      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)

    2. terryjreedy commented on May 2, 2008

      @terryjreedy
      Member

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

    3. serwy commented on May 3, 2008

      serwymannequin
      MannequinAuthor

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


    4. kbkaiser commented on May 4, 2008

      @kbkaiser
      Contributor

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

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

    5. self-assigned this
      on May 4, 2008
    6. cben commented on Jun 4, 2008

      cbenmannequin
      Mannequin

      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.

    7. serwy commented on Jun 17, 2008

      serwymannequin
      MannequinAuthor

      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.

    8. terryjreedy commented on Aug 8, 2008

      @terryjreedy
      Member
      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.

    9. bmiller commented on Mar 11, 2009

      bmillermannequin
      Mannequin
      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.

    10. kbkaiser commented on Apr 2, 2009

      @kbkaiser
      Contributor
      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....
    11. kbkaiser commented on Apr 2, 2009

      @kbkaiser
      Contributor

      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!

    12. terryjreedy commented on Apr 2, 2009

      @terryjreedy
      Member

      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.

    13. kbkaiser commented on Apr 3, 2009

      @kbkaiser
      Contributor

      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.

    14. 17 remaining items

    15. SeanWolfe commented on May 12, 2015

      SeanWolfemannequin
      Mannequin

      Windows 7 patch test successful:

      https://bugs.python.org/issue2704

      • install python 2.7.8 fresh on W7
      • 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.

    16. SeanWolfe commented on May 12, 2015

      SeanWolfemannequin
      Mannequin

      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 .

    17. terryjreedy commented on May 14, 2015

      @terryjreedy
      Member

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

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

    18. terryjreedy commented on May 14, 2015

      @terryjreedy
      Member

      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.

    19. terryjreedy commented on Aug 1, 2020

      @terryjreedy
      Member

      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.

    20. transferred this issue fromon Apr 10, 2022
    21. added
      type-featureA feature request or enhancement
      and removed
      type-bugAn unexpected behavior, bug, or error
      on Feb 6, 2025
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions