Author terry.reedy
Recipients cben, kbk, roger.serwy, taleinat, terry.reedy
Date 2012-01-17.00:55:02
SpamBayes Score 2.22045e-16
Marked as misclassified No
Message-id <>
I closed #8285 as it merely reported a consequence of using tabs.

The Command Prompt window used for interactive Python on Windows only uses fixed-pitch fonts. Idle (tk) allows any font. I happen to use Lucida Sans Unicode (variable pitch) for what I think is the largest set of glyphs. (Perhaps Lucida Console (fixed) has the same set, I don't know. See #13802 for an idea to improve font selection in this regard.) Whatever we do should work well with either fixed or variable pitches. (The current patch does not -- see below.) Or we should prohibit variable pitch fonts and only allow fixed pitch fonts

Selection in CP selects a rectangle, so one can select code with or without the prompts. This is only possible with fixed pitch. Tk text boxes are limited to selecting a continuous stream of text, without excluding a margin.

This contrasts with, for example Notepad++. Its (tabbed) edit window has a gray left margin with line numbers. Then it has a narrow lighter gray column with [-] and [+] boxes to collapse and expand indented regions. Then it has a white text box for user entry and only user entry. Selections ignore the gray margins and only select within the white user text box. Perhaps this is done by tying three borderless windows to one vertical scroll bar, all inside one frame. I don't know. If we could do the same with tkinter, we could put prompts in a grayed margin, but I do not know if we can.

CP has tab stops at every 8 chars. So if one indents with tabs, the first indent is 4 spaces past the prompt and further indents are 8 spaces beyond the last. Not good. The alternative is hand spacing. Also not good if you do very much. Idle (Tk) appears to have tabs at fixed positions, regardless of the font. (Notepad++ acts like IDLE's edit windows -- a tab in converted to 4 spaces.) In Lucida Sans, a tab is physically the same as 16 spaces. Since each '>' is 3 spaces, an indent of 8 spaces instead of a tab is a dedent on the screen. So the patch does not work for me.

My conclusion is that having the shell write a prompt onto the user entry line, in the tk environment, is incompatible with the behavior we want. Fix 1 would be to put the prompt on a line by itself ('>>>\n' or 'input>\n'), use the same indents as the editor, and add an similar output marker ('###\n' or '<output\n'). Option 2 is to omit prompts, use editor indents, and prefix every output line with '#'. Fix 3 would be to put the prompt in a grayed margin. (If this can be done, we could also add line #s as an editor option.)

A separate idea is to give output a colored background.

Date User Action Args
2012-01-17 00:55:04terry.reedysetrecipients: + terry.reedy, kbk, cben, taleinat, roger.serwy
2012-01-17 00:55:04terry.reedysetmessageid: <>
2012-01-17 00:55:03terry.reedylinkissue7676 messages
2012-01-17 00:55:02terry.reedycreate