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

Rick Johnson rantingrickjohnson at gmail.com
Mon Jul 21 03:22:37 CEST 2014


On Sunday, July 20, 2014 4:52:36 PM UTC-5, Terry Reedy wrote:
> On 7/19/2014 9:31 PM, Rick Johnson wrote:
> > On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:

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

Speaking strictly from the point of view of the *current*
IDLE implementation, yes.

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

Actually, the "problem" you are describing is fundamentally
different from what i was talking about, but you *are* getting
closer to the *real* source of the design flaws that prevent
*easy* evolution of the IDLE software.

The *real* problem is that the "interactive events" of the
"editor window" and the "interactive events" of the "shell
window" are far too tightly integrated with one another. 

I myself appreciate the finger saving principles of "DRY",
however, sometimes, two distinct functionalities just 
cannot be implemented *IN A CLEAR MANNER* without repeating
*some* of the code.

We need to understand that IDLE is split into two distinct
"modes", if you will -- the "interactive shell" and the
"editor window". Attempting to use the same code to handle
keystrokes for the shell *AND* the editor is a stumbling
block to extending this mess. 

Instead, IDLE needs two distinct "pipelines" for which
events for each *SIDE* of this "split personality" can be
*written* and later, easily *COMPREHENDED* by the
maintenance programmer.

Our "real problem" is discombobulation, and until we wrangle
the beast of discombobulation, we will never improve this
software in a meaningful or clear manner. Instead, we will
only render the software exponentially less readable.

    YOU CANNOT IMPROVE ANY SOFTWARE UNTIL YOU CAN GROK IT'S SOURCE

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

Yes and no. ;-) 

Hiding the "secondary prompts" from the "execution server"
is as simple as running the "command" through a "cleaner
function" *BEFORE* it gets evaluated.

As for the other issue of protecting the user from editing
the "secondary prompts", all you need to do is add a few
bits of extra logic to the backspace and clipboard events. But
you *could* even just let the user be responsible for his
own mistakes and allow documentation handle that issue.

But either way, both can be achieved without a complete re-
write *OR* fundamental architecture re-design.

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

That sounds fine to me. There are many methods one can
utilize to differentiate input from output. And i like your
idea of input being black(with colorizer modification of
course), valid output as *ALL* blue, and error output as
*ALL* red.

> Ideas don't count until recorded on the tracker.

Hmm, okay.

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

How can i offer improvements if i don't know where to find
the code? And besides, if my comments here "don't count" i
will levy the punishment of Eric Theodore Cartman upon you:

    SCREW YOU GUYS, I'M GOING HOME!



More information about the Python-list mailing list