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

[Chris Angelico]

On Mon, Jul 21, 2014 at 7:52 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 7/19/2014 9:31 PM, Rick Johnson wrote:
> 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?)

If you mean that individual lines are separately edited, then yes,
that's the same on Linux.

> 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.

This is, in fact, Idle's greatest feature IMO. The ability to recall,
edit, and resubmit an entire function/class definition as a single
unit.

> 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.

If you're weighing up those two options specifically, I would tip the
balance toward a custom copy. If you paste into some other
application, it would be more consistent to work with four spaces for
every indentation level, rather than having every line begin with a
tab and then some spaces.

> 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.

The secondary prompts are actually quite annoying in copy/paste.
Anything that suppresses them is a distinct advantage IMO.

> 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.

I'd have to have a look and see how that feels before I can judge
properly, but the notion of output not being indented by a prompt is
one that's found on... well, pretty much everything. Most command-line
interfaces work that way. Good MUD clients work hard to make sure that
the user's input is correctly indented by the prompt, even if the two
are quite separate in chronology; if you use input("........") and
print(), you'll end up with the same kind of interface. Explaining the
difference in color will be different, so it'll have to work extra
well to make up for that. Also, you can copy and paste into an email,
which will lose color. Count me dubious but reserving judgment.

>>    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.

Huh, is combined scrolling really such an amazing thing? Only one
person in the whole world knows how to do it? So.... like this:

http://www.phdcomics.com/comics/archive.php?comicid=1723
http://catb.org/esr/writings/unix-koans/mcse.html

Considering that some GUI toolkits have that functionality as a core
feature (GTK scrolling is a bit more complex to support this exact
concept), I would be very much surprised if exactly one person knows
how to do it in Tk.

> 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?

I can't comment on how it interacts with the editor half of Idle, but
for the shell as a stand-alone app, and for copying and pasting into
other programs, this last idea is rather interesting. I'm broadly
happy with the current system (>>> def f(x):), and the prompt is a
little weird (">>>:"? but maybe "Python:" would be less weird; I don't
advise "Idle:" as it implies that something is idle that might be
busy), but this would make copy/paste that bit easier. It would tend
to de-emphasize the difference between input and output, though, which
may or may not be an issue. But definitely interesting.

ChrisA