On 7/19/2014 9:31 PM, Rick Johnson wrote:
On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:
Idle's Shell currently uses a primary prompt ('>>> '), no secondary
prompt*, and tabs for indents. This is a compromise between conflicting
goals. It works but perhaps we can do better.
* The third paragraph below explains that Shell's prompt is a statement
prompt rather than line prompt, so that a secondary line prompt would
not be appropriate.
The problem with tabs is that tk displays them as a jump to the next
'tab stop'. For fixed pitch fonts, the virtual tab stops are set at 8
space intervals. For proportional fonts, I suspect the spacing is 8 em
quads, where an em quad is the height of the font, which is also about
the width of the widest character. An em quad is much larger than the
width of a space character, perhaps 4x larger and perhaps 1.5 times the
average width. Because of no secondary prompt, the first fixed-pitch
indent looks like an indent of 4 spaces after a 'secondary prompt' of '
', while subsequent indents are really 8 spaces. The indents appear
are uneven and the subsequent indents chew up screen width too quickly.
For proportional fonts, the problem is worst as the indents are about
12 characters.
http://bugs.python.org/issue7676
indention. I know this issue is going to be a bit more
trouble to solve than the previous two "event" issues
To understand *HOW* we might resolve this issue, *FIRST* we
must understand the origins of the issue
The problem originates in differences between the console - interactive
python interaction and Idle Shell - execution server interaction.
Interactive python prints prompts to and reads lines from the console.
Once the user submits a line by hitting return, it cannot be edited.
(This is true on Widows. Could any linux and mac user confirm for their
systems?)
The Idle Shell is much more active than at least the Windows console,
and it is statement rather than line oriented. This is the important
point. The Shell '>>> ' prompt is prompting for a complete statement,
not a single line. This difference of meaning should be documented if it
is not now.
Until a user indicates that a statement is completed, the user can edit
*any* part of the statement, not just the last line. While Shell
monitors keystrokes and modifies the text accordingly with color and
indents, it does not send the statement to the execution server, which
is running idle code in batch-mode python, until the statment is
complete. The execution server then exec()s the statement inside the
Executive.run_code method and sends and response back.
Being able to enter, edit, and recall complete statements is an valuable
Shell feature.
The problem manifests itself when the user wants to write
> commands that span *MORE* than one line.
Right. Multiline statement issues go away when a statement is a single
line. Now to the ideas on the tracker.
IDEA_1: Hey, lets just use 8 space indention for the
Or a tab for the first indent (this works if consistent)
*FIRST* level of indentation, and 4 space indention for
any *SUBSEQUENT* levels of indentation,
I am considering this as an option when the font is fixed pitch.
that would not solve the copy-paste problem *DIRECTLY*,
The advantage of a single tab is that it is easy to turn it into 4
spaces either in a custom copy or after pasting.
IDEA_2: Hey, lets just insert a "buffer prompt" for every
line that is *NOT* the *FIRST LINE* of the command, and
then use 4 spaces for indention... problem solved!
RESPONSE_2: Hardly! Can't do that because people cannot be
denied their "adolescent accessorizing" via font choice.
This idea, and your response, ignores the fact that Shell is *statement*
oriented. Inserting a secondary prompts inside statement text would mean
that they would have to first be protected from user editing and then
deleted by Idle before the statement is sent to the Executive.
IDEA_3: Hey, let's remove the embedded prompt from the
main shell window altogether and display it in a separate
"thin" area to the left -- sort of like how line numbers
are displayed in other IDEs. This would solve the copy paste
> issue *AND* the indention issue.
http://bugs.python.org/issue17535
GSOC Idle student Saimadhav Heblekar has worked on adding *optional*
line numbers to Idle editor windows. I plan to adapt the final patch to
the shell with, for instance '>>> ' and 'out:' labels.
As I said on the tracker, I think that output that is no longer dedented
with respect to input will then need some more to distinguish it. For my
copy of Idle, I have added blue and red background tint to standard and
error output and I think that works well.
we can take credit for Ricks idea from circa 2005,
Ideas don't count until recorded on the tracker.
RESPONSE_2: You fool! That would require *ACTUAL* skills
that we *DON'T* have. Only rr knows how to "lock" the
scrolling events of two Tkinter widgets,
Saimadhav has locked together a thin canvas with the text for line
numbers. It works in all my texts. I am just waiting for him to try it
with a thin text instead.
If you know some secret you think he missed. please describe it here.
Idea 4 (which I already suggested on the tracker). Put statement input
prompts and output separators on lines by themselves. As with 3. above,
use standard 4 space indents, as with
>>>:
def f(x):
if x:
print('got it')
return 'something'
>>>:
f(3)
---
got it
>>>:
Idle users other than Rick, any comments on the possible improvements?
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
