Improving Idle (was Re: Python 3 ...)

[Rick Johnson]

On Saturday, July 19, 2014 3:45:07 PM UTC-5, Terry Reedy wrote:
> On 7/19/2014 12:29 PM, Rick Johnson wrote:
> [2.7.2 and 3.2.2] are ancient versions from years ago that
> no one should be running Idle on now.

I have just downloaded and installed versions 2.7.8 and
3.4.1, and i am happy to report that both the "HOME_KEY"
*AND* the "CONTROL+LEFT_ARROW" events are working properly
and intuitively. I also would like to give my deepest
gratitude and thanks to those who corrected these
abnormalities!

    KEEP UP THE GOOD WORK GUYS!

> To repeat: I agree [that tab indention is bad], Raymond
> Hettigner agrees, everyone seems to agree, and we all have
> for years. http://bugs.python.org/issue7676 is over 4
> years old.  But a patch can only implement a specific new
> behavior, not just 'stop the old'.

Just checked 3.4.1, and it is still using a tab for
indention. I know this issue is going to be a bit more
trouble to solve than the previous two "event" issues that i
mentioned, however, i feel it is an important issue to
solve.

To understand *HOW* we might resolve this issue, *FIRST* we
must understand the origins of the issue -- and as such, a
few basic "rules" of how the IDLE shell "interacts" with a
user is prerequisite.

  1. The shell presents a prompt (in the case of the IDLE
  shell the prompt is ">>> "), as a "starting" point for
  interactive commands.

  2. The user begins typing his command at the prompt...

    2a. In the process of typing his command, each time the
    user presses the "ENTER" or "RETURN" keys (which i shall
    from now on refer to them *singularly* as the: "ER-
    KEYS"), the shell "intuits" whether the user intended to
    complete his command "at-the-current-line" *OR* that the
    user intends to "continue-writing-more-code", on
    subsequent lines.

    Note: As you can see the actions taken by pressing the
    "ER-KEYS" depend on the context in which they where
    pressed! If the command is "believed" to be *COMPLETE*,
    then the action will be: "evaluate the users command now
    and display a result", however, if the command is
    "believed" to be *INCOMPLETE*, the action will be:
    "allow the user to continue entering his command".

    2b. If the "shell" believes that the user is finished
    writing his command, the shell will evaluate the
    *ENTIRETY* of the command (which could span one or more
    lines!) and then display the result of that evaluation
    *BENEATH* the command, however, if the shell "believes"
    that the user intends to "continue-writing-more-code",
    then the shell will allow the user to continue writing
    more code.

  STEP[N:]. There is much more to the interaction between
  "shells" and "users", however, these first two steps, and
  their subsequent "sub-steps", are all we need to concern
  ourselves with at this time, in order to solve *THIS*
  particular problem.

Now, between the "shell" and its "user" exists a contract,
and the preceding steps i outlined describe most of thast
contract, however, i realized that i can describe the full
contract more clearly by conflating the "shell" with "god"
and the "user" as some poor disciple. If we view the
contract through "the eyes of a *GODLIKE* shell" it might
read something like:

  And the "shell" so-eth declared:

  Ye shall be presented with a prompt, and from that prompt
  thou shalt humbly enter requests. When i find thouest
  requests pleasing, i shall reward thou with my vast
  knowledge by displaying to you the result utilizing an
  esthetically pleasing shade of blue, HOWEVER, shall i find
  thou request to be illogical or malformed, i shall punish
  thou with furious displays of my rebukes, utilizing the
  "fear color" of *BLOOD* red! And thou shalt know my name
  is the SHELL!

  Furthermore, ye shall not be allowed to edit previous
  request, no matter how blasphemous they may be! No, they
  shall live as a testimate to thouest ignorance, a *PUBLIC*
  testiment for all to see -- until which time thou decideth
  to terminate our contract.

Now that we understand the contract between "shells" and
"users" we can focus in on the problem. The problem
manifests itself when the user wants to write commands that
span *MORE* than one line. For instance, when i write the
first line of a "multi-line source code" like this:

    >>> for x in range(10):

And then i press the "enter key", the current IDLE shell is
going to insert a tab char (not good!), when it *SHOULD*
have inserted a "buffer prompt" of some kind, and then
calculated the correct "extrapolation-indentation" (by
adding four to the indent of line #1, which is four!) for
this new line of code.

    >>> for x in range(10):
    ...     do_something

Notice the "buffer prompt" of "... ", after which follows
the "extrapolation indent" of "    ", after which defines
the *BEGINNING* of my next command of "do_something"? Seems
simple enough huh? Oh but, my friend, *NOTHING* is simple in
this damn community is it!

============================================================
 Summary of the attempts to solve "INDENTION ISSUE" (at IDLE Bugs)
============================================================
The comments on how to solve this problem read like a book
titled: "devils advocate for dummies".

  IDEA_1: Hey, lets just use 8 space indention for the
  *FIRST* level of indentation, and 4 space indention for
  any *SUBSEQUENT* levels of indentation, that would not
  solve the copy-paste problem *DIRECTLY*, however, it would

  RESPONSE_1: Shhhhh! Are you nuts! Be quiet! We cannot
  allow such easy remedies, because if we did, we would not
  need a bug tracker! No sir, this software dev team takes
  the protestant approach to problems -- we will suffer and
  we will like it!!!


  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.
  How can you expect people to use *ONLY* mono-spaced fonts,
  i mean, geez, that's fascism! Besides, web-dings is vital
  for the those of us who need to encrypt our code so
  "peeping toms" cannot steal our snippets -- you never know
  who might be watching!

      >_>

      <_<


  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. Plus, we can take
  credit for Ricks idea from circa 2005, nobody listens to
  him anyway!

  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, plus, he'd have
  to change the underlying design of the entire shell
  contract in such a *DRAMATIC* fashion that he'd be better
  off just starting from scratch -- the IDLE source is a
  discombobulated mess!

Does the IDLE bug-tracker exist to *SOLVE* problems or to
*PERPETUATE* them?

> If you are running your tkinter code in the same process
> with Idle's tkinter code, either with ancient Idle or the
> '-n' startup option (possibly buried in a script), the
> situation is hopeless. If you are running your code in a
> separate process (now the default), then, most likely,
> Idle is not hanging. It is just waiting for your hung
> process. If so, Shell / Restart shell (^F6) will end the
> user process and start a new one.

Now that i have the most current releases of both Python2
and Python3, i will use IDLE exclusively to determine if
this "hanging issue" has been resolved, and if it has, i
will go from IDLEs loudest dissenter, to it's most exuberant
supporter.

Granted, this "hanging" issue is not the *ONLY* remaining
issue, however, it is the *SOLE* issue that has motivated me
to stop using the software and write my own. I will only
change my position once i have not experienced this nuance
for a reasonable time... and only time will tell.

> Use one of the startup options directly above to see if
> you can get more information.  A repeatable or at least
> semi-repeatable failure case is needed to do anything.

Yes. The very next time i get a hang, i'm going to post a
test case for all to see, so we might figure this out.

> > However, *EVEN* in the instances where a problem is a
> > direct result of a "Tkinter NO-NO" (being witting or
> > unwitting), the user of IDLE should *NEVER* be forced to
> > kill processes
> If you are talking about user processes, and we are
> talking about patching Idle, as opposed to Python or the
> OS (such as Windows), I disagree. If you are talking about
> the Idle process, then yes, I would prefer that once Idle
> starts, it run forever, and recover from any problems
> caused by users. Roger Serwy fixed many Idle shutdowns
> before being swallowed by a PhD program a year ago, but
> there is more to do.

My point is, that, when i run a Python program using
"IDLE->Run->Run Program", i expect that IDLE is going to
execute my program, catch any errors, and then report them
to me. What i don't expect, is that IDLE is going to hang,
freeze, churn, or totally go bonkers.

If IDLE, which is written in Python, cannot understand when
a Python program has failed, and take necessary actions to
exit cleanly *OR* allow the user to *MANUALLY* exit cleanly
at *ANY* time, then it is useless as an IDE, and should be
"repackaged" and "sold" as a "texteditor(with aspirations of
being an IDE one day)".

    IF YOU CAN'T RUN WITH THE BIG DOGS, STAY ON THE PORCH!

PS: I do promise though to hold an optimistic view until
proven otherwise.