[issue7676] IDLE shell shouldn't use TABs

Terry J. Reedy report at bugs.python.org
Sun Jul 20 00:49:31 CEST 2014


Terry J. Reedy added the comment:

The problem with just /\t/    / is the absence of a secondary prompt.

>>> def f():
    return 'not acceptible'

Hence the 8+4+4... proposal. With a proportional font, the return would start to the *left* of def. Adding '... ' works for fixed pitch fonts, but '...' is much narrower than '>>>' in a proportional font.

The problem with mandating 'fixed pitch' is that unicode fonts, such as Lucida Sans Unicode on Windows, are proportional.  With that font, spaces are very narrow: '8+4' would need to be 13 + 4 + 4 ... to look right, *on Idle*.  I feel that continuing to work with proportional fonts, for code not limited to ascii, is more important than this issue.

To look right regardless of font, code should start at the margin, with prompts in a separate narrow window. This means that output would not be dedented under input prompts.
---------------------------------------
 in> def f():
         print('code against margin')

out> code against margin
---------------------------------------
' in> ' and 'out> ' (or whatever input and output indicators were used) would be in a vertical strip (like line numbers) with, say, a light gray background (such as used here).  Normal output would be, say, the current blue on a very light blue background. Similarly for red stderr output. It takes very little tint to be distinct from a white background. I have set my custom configuration to try this out.

Cutting code is a different issue. As I said above, I think custom functions are needed. One could only cut code. Another could add '>>> ' and '... ' before input lines, for pasting into docstrings. Another could add '# ' before output lines, for pasting into messages in a form that readers could recut and paste into an editor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7676>
_______________________________________


More information about the Python-bugs-list mailing list