Idle's Shell: prompts and indents (was ...) Idle users please read

[Terry Reedy]

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