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