This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: allow using normal indent width in shell in IDLE
Type: Stage:
Components: IDLE Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: kbk Nosy List: jimjjewett, jshute, kbk
Priority: normal Keywords: patch

Created on 2005-05-06 23:26 by jshute, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
usetabsinshell.patch jshute, 2005-05-06 23:26 patch
usetabsinshell2.patch jshute, 2005-05-12 04:46 new version of patch
Messages (4)
msg48309 - (view) Author: Jeff Shute (jshute) Date: 2005-05-06 23:26
IDLE currently ignores the indent width setting in the
main shell window, and forces it to use tab characters,
8 spaces wide.  This is ugly, and causes problems when
you write code in the shell and then cut-and-paste it
into a real editor window.

This patch adds an option (off by default) to honour
the indent width setting in the PyShell window rather
than using tabs.  This makes it much nicer to edit
commands that use several levels of indenting.  

The only reason for this to be an option, and for it to
be off by default, is that it looks a little weird when
the second line of code is indented, but still lines up
with the first indented line because the prompt is also
4 characters wide.  Fixing it so this would not look
weird would be nice, but would require a lot of Tk
hacking and might make the gui slower.
msg48310 - (view) Author: Jim Jewett (jimjjewett) Date: 2005-05-11 23:02
Logged In: YES 
user_id=764593

Would using a continuation prompt of " "*len(sys.ps1) solve 
the problem?  (standard module) code uses a continuation 
prompt of "... " which gets the spacing right, though it doesn't 
do your indents for you.
msg48311 - (view) Author: Jeff Shute (jshute) Date: 2005-05-12 04:46
Logged In: YES 
user_id=39615

Hmm, I had only considered using a continuation of "...". 
Using spaces would make things look mostly right, and will
have odd behaviour only when you cut-and-paste into an
editor, since you will get an extra indentation level, but
that won't cause errors and is easily fixed.

Here is a new patch that implements it this way.  I think
doing it this way solves the problem well enough that the
preference is not necessary.  (Or both patches can be
applied to get this behaviour and the preference.)
msg48312 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2007-02-05 04:30
Sorry. Doesn't really solve the problem.
History
Date User Action Args
2022-04-11 14:56:11adminsetgithub: 41957
2005-05-06 23:26:20jshutecreate