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! -- https://mail.python.org/mailman/listinfo/python-list