Terry J. Reedy <tjre...@udel.edu> added the comment:
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.
Thoughts?
----------
nosy: +terry.reedy
stage: needs patch -> patch review
versions: -Python 3.1
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue7676>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
