On 17/06/12 02:12, Terry Reedy wrote:
That is exactly what I mean. The first four *fixed width* characters are
off limits to the user.
OK, I see what you mean now. And that's a by-product of the DOS box only
allowing mono-spaced fonts (I think, its been a while since I used
Windows DOS boxes!)
>>> and consequently the first indent may not look like an indent.
Indeed, with Lucida Sans Unicode, '... ' is *shorter* than '>>> ',
so that the first indent is visually a dedent! This is not acceptible.
But better than the current situation with no secondary prompt - at
least you can see that there is some kind of indent wrt the prompt.
I consider having the first indented line start to the *left* of the
unindented line above to be worse than the current situation.
But that is the current situation in IDLE? With no secondary prompt the
first indented line often starts to the left of the unindented line above.
But in Python anyone who uses non mono-spaced fonts for coding is asking
for trouble IMHO!
I do it regularly, with little problem. In Python 3, both text and
identifiers are unicode. I do not know that there are any fixed-pitch
unicode fonts. It would make ascii chars spaced too far apart.
Hmm, you've lost me there. What difference does Unicode make to the
display? Surely Unicode only affects how many bits are used to store the
characters not how they are displayed?
has to accommodate Python 3.x code, which include unicode identifiers as
well as strings.
Sure, Python can work with non mono-spaced fonts - always has - but they
can mess up indentation so that off-by-one-space errors are hard to
spot. (Not so big an issue if you always use tabs for indents I
guess...but that's another debate! :-)
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
http://mail.python.org/mailman/listinfo/idle-dev
