You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
allow using normal indent width in shell in IDLE #41957
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/kbkaiser'closed_at=<Date2007-02-05.04:30:32.000>created_at=<Date2005-05-06.23:26:20.000>labels= ['expert-IDLE']
title='allow using normal indent width in shell in IDLE'updated_at=<Date2007-02-05.04:30:32.000>user='https://bugs.python.org/jshute'
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.
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.
jshute commented on May 12, 2005
jshutemannequin
MannequinAuthor
More actions
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.)
Activity
jshute commentedon May 6, 2005
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.
jimjjewett commentedon May 11, 2005
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.
jshute commentedon May 12, 2005
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.)
kbkaiser commentedon Feb 5, 2007
Sorry. Doesn't really solve the problem.