Repository navigation
IDLE - clear and restart the shell window #50393
Description
| BPO | 6143 |
|---|---|
| Nosy | @rhettinger, @terryjreedy, @serwy, @rovitotv, @alex, @ZackerySpytz, @PythonCoderAS |
| PRs | |
| Files |
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 2009-05-29.21:09:50.429>
labels = ['expert-IDLE', 'type-feature', '3.11']
title = 'IDLE - clear and restart the shell window'
updated_at = <Date 2022-03-02.03:49:24.032>
user = 'https://github.com/serwy'bugs.python.org fields:
activity = <Date 2022-03-02.03:49:24.032>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2009-05-29.21:09:50.429>
creator = 'roger.serwy'
dependencies = []
files = ['14116', '14303', '34145', '34146', '34200']
hgrepos = []
issue_num = 6143
keywords = ['patch']
message_count = 31.0
messages = ['88539', '89319', '89387', '185485', '186033', '211032', '211044', '211056', '211066', '211067', '211073', '211074', '211310', '211641', '211642', '211644', '211663', '212020', '212051', '260912', '272835', '272843', '287735', '287791', '319869', '333251', '359256', '359265', '374596', '374626', '414323']
nosy_count = 8.0
nosy_names = ['rhettinger', 'terry.reedy', 'roger.serwy', 'THRlWiTi', 'Todd.Rovito', 'Alex', 'ZackerySpytz', 'ThePokestarFan']
pr_nums = ['21682']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue6143'
versions = ['Python 3.11']Metadata
Metadata
Assignees
Projects
- Status
Activity
serwy commentedon May 29, 2009
I noticed that the feature to clear the shell window has been a
discussion topic in the IDLE-dev archives for a few years. Here's an
extension that can clear the contents of the shell window. It provides
"Clear Shell Window" under "Options" and a <Ctrl-L> key binding.
The source code provides two methods to do this. The
ModifiedUndoDelegator prevents changing the contents of the text widget
before "iomark". One solution is to disable the filter, make the
changes, then re-enable it. Another solution is move "iomark" to the
beginning of the document. Any thoughts?
taleinat commentedon Jun 13, 2009
First of all I think that the Squeezer (issue bpo-1529353) extension is
more useful and solves most of the problems that this proposed feature
is set to solve, e.g. issue bpo-1442493.
IMO the second method you offer - temporarily moving "iomark" - is
preferable.
One reason is that it will allow using the undo feature to undo deleting
the entire shell history. I think this is important since deleting the
history by accident without a way to retrieve it would be very annoying.
I propose going with the clear_window2 method, wrapping it with
undo_block_start() and undo_block_stop().
serwy commentedon Jun 15, 2009
I just tried Squeezer. It's pretty neat and it solves a different
problem. Clearing the contents of the shell window should be a simple
operation.
The undo operation doesn't restore iomark properly, nor does it restore
tags. I've uploaded a newer version of the extension to handle undo.
Binding to the "<<undo>>" virtual event with add="+" didn't work as
expected, so the new undo event handler explicitly calls the older one.
I admit that this code is not ideal.
Should I move this extension to the Cheese Shop and close out this issue?
serwy commentedon Mar 29, 2013
The ClearWindow.py extension as included in the IdleX package contains a more recent version that allows undo with full color tag restoration.
serwy commentedon Apr 4, 2013
In bpo-17632, Raymond suggests adding a "Restart and Clear" menu item under the Shell menu.
taleinat commentedon Feb 11, 2014
Removing text before "iomark" can be done by using the underlying Text widget directly. See how the Squeezer extension does this in bpo-1529353. This should simplify the implementation significantly.
I also took a look at the version of the extension in IdleX. I'm thinking of adapting this for CPython's IDLE. Some questions:
serwy commentedon Feb 11, 2014
I agree that the underlying .delete can be called directly, bypassing
the ModifiedUndoDelegator in the percolator chain. I have mixed opinions
about the Percolator, but that's another issue.
There is no compelling reason. I agree that it should be moved to .do()
That's an artifact from earlier code for IPython compatibility. The
colored text prompts in IPython use ANSI escape codes, and the older
undo code reinserted the text without restoring tags.
Using text.dump() and the restore routine in undo() now restore the tags
and eliminates the need for strip_ansi(). I haven't removed that old
code yet.
IDLE itself does support multi-line prompts. The debugger is a whole
other can of worms.
It should work on regular IDLE. IdleX wraps the existing CPython IDLE.
taleinat commentedon Feb 12, 2014
Roger, thanks for the quick response!
I'll try to get to working on this in the coming days.
taleinat commentedon Feb 12, 2014
Terry, if I wrote an appropriate patch, would it have a chance of being accepted?
terryjreedy commentedon Feb 12, 2014
Without having read the dialog to know what you mean by appropriate, and how a new patch would be different from Roger's 5 year old patch, or how this issue relates toSqueezer, yes. I have occasionally closed the shell and reopened (perhaps by running a file) to clear the shell. I would like to reduce the need for that by putting help output in a separate read-only output window. But there is still the occasional 2000 line traceback for hitting the recursion limit, and other mishaps.
30 remaining items
terryjreedy commentedon Jul 31, 2020
@PokerStar: First we have to agree on several things.
What is the need, what are the use cases? When do *you* feel a need to clear the shell?
What is the basic strategy?
a. Delete selections: make delete, backspace, and cut work in the shell, as in editor.
I prefer this. No new doc or menu entries needed.
People can delele less than everything.
b. New feature. All or nothing. Changes 8 files. There was discussin of how to delete, but seems not difficult.
Details need to be agreed on.
If new feature, menu entry and shortcut: I thing 'Clear shell' is enough. Patch disagrees with discussion on shortcut.
Should header be deleted or left? (Delete selection lets user decide.)
Should deleted text be undoable? We do not currently allow any editing of shell history? Undo amounts to pasting or retyping, and if we do not allow pasting or typing in general, why with undo?
Should squeezes text be expanded? I think not. help(tkinter) produces over 22000 lines.
Should the current prompt and any code be deleted? I think not. If prompt gets deleted, it has to be re-written, but without current in-process entry.
Should remote process be restarted? Why? This can easily be done independently and might not be wanted.
<probably something else>
New behavior must be tested. The is usually the hardest part of a patch, which is why it is neglected. Incomplete testing may result in adding a new bug. It was just reported that closing IDLE while the Shell is waiting for a response to input(prompt) leads to incomplete shutdown and a zombie process. On macOS, this can lead to a crash and possibly a need to reboot.
So, should we allow clearing, deletion while user code is executing? While user code is requesting input? Or must we prohibit? I don't know, other than this must be tested at least on Windows and macOS.
Overall, I prefer to use the deletion mechanism we have, rather than add a new one.
terryjreedy commentedon Mar 2, 2022
https://stackoverflow.com/questions/71290382/how-do-i-adjust-python-idle-shell-settings-so-that-the-next-line-of-code-i-type
is from someone who, for whatever reason, likes having blank space in the shell below the input prompt. It is not clear whether deleting lines to make that happen would be satisfactory, or if all lines must be accessible.
jamesderlin commentedon Jun 16, 2025
For whatever my opinions are worth:
My use case would be for introducing someone to programming where the IDLE shell showing them old error messages and output is potentially confusing, especially if they're primarily using the editor window and choosing "Run" rather than using the shell window interactively.
Currently I suppose people can close and reopen the shell window if an editor window is left open, but closing/reopening the shell window is awkward, especially since it currently does not preserve its previous window placement.
I do not like (A). Allowing delete or backspace to work directly in the shell window would make it more like the editor window, and that could be more confusing. It also would be confusing if someone accidentally deleted text from the shell window without realizing it.
A "Clear shell" menu sounds fine to me, but I think "Clear and restart shell" probably would be much simpler (see point 4 below) and would be sufficient for most people.
I don't see a need for a keyboard shortcut/hotkey since people can use still use the keyboard with menu accelerators.
If clearing would also restart the shell, then IMO the shell window should look the same as when it was initially started.
I'd prefer an all-or-nothing clearing ability not allowing arbitrary deletion of text from the shell window, and for that scenario I think it'd be fine to not have any undo capability.
With an all-or-nothing clearing ability, everything would be cleared anyway.
If clearing is tied to restarting the shell (i.e., if the menu item is "Clear and restart shell" menu or if it's some checkbox when restarting the shell), then the testing scenarios should be the same as for restarting the shell.
terryjreedy commentedon Oct 6, 2025
@jamesderlin Thanks for the comments.
I think there are two main uses cases, which would have different solutions.
Anything else could likely be handled be saving with prompts (or save with output commented -- to be added) and editing in editor.
terryjreedy commentedon Oct 6, 2025
Before doing anything, I would likely open an 'Ideas' thread on discuss.python.org.