On Friday, July 18, 2014 8:21:36 PM UTC-5, Terry Reedy wrote:
> What ancient version, or oddball system are you using? For
> me, Win 7, both 2.7.8 and 3.4.1 "CONTROL+LEFT_ARROW" and
> the cursor is before the 'a' of [>>> abc]. The HOME key
> goes to the same place first, and they before >>> on the
> second press (and before 'a' on the third).
On versions 2.7.2 and 3.2.2 CONTROL+LEFT_ARROW is landing
*properly* in front of the prompt, so apparently that bug was
fixed since last i checked, my apologies for being ignorant
of the situation, but you should understand that i had given
up after years of no improvements.
However, a *bare* HOME_KEY press is placing the insertion
cursor *BEHIND* the prompt of the current line. In a shell
environment, you never want to be *BEHIND* the command
prompt.
Now, in the case of CONTROL+HOME (which places the insertion
cursor at the very *first* position of the entire text
buffer) and CONTROL+END (which places the insertion cursor
at the very *last* position of the text buffer), we should
leave the default behaviors alone. I don't see any benefit
of changing them.
> "IDLE shell shouldn't use TABs" is a high-priority for me.
> The problem is agreeing on an *exact* specification for
> new behavior, that takes into account both the limitations
> and flexibility of tk. Maybe I should start a thread here
> or python-ideas, where people are willing to discuss
> details.
First, i need to admit that i was wrong when i said: "eight
space indention", since the IDLE shell is using *tabs* for
indention, not spaces! However, a single tab is just as
annoying as 8 spaces
Now, even as much as i dislike tabs, i must admit there is a
benefit to using tabs over spaces, since tabs require only
*ONE* backspace key-press per "pseudo 4 spaces" as compared
to spaces which require a 1:1 ratio of key-presses. Of
course, even this problem can be abstracted away by
"backspace automation code", which the IDLE editor window
already employs!
But my point is: We *MUST* remove this *excessive*
indentation width from the IDLE shell!
> I cannot connect [your complaint about IDLE hanging] to
> behavior I have seen.
IDLE will hang when editing Tkinter code. It seems to happen
most often in two cases:
1. When running code that results in a Tkinter error.
This can happen when mixing the "grid" and "pack" geometry
managers within the same "container" widget, which is a
Tkinter NO-NO, but it can also happen during other Tkinter
errors!
2. During "quickly successive" back-to-back "run sessions"
of Tkinter GUI apps.
It seems that sometimes, if you don't give IDLE enough
time to release resources from the *LAST* run session, it
will freeze and then throw a "sub-process connection
failure" message, which, sometimes you can remedy by just
"trying again", but all to often you are forced to kill
the entire IDLE (and related sub-) processes.
THIS IS EXTREMELY ANNOYING!
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
because:
THERE MUST BE A BETTER SOLUTION!
And this bug is making the whole Python community look like
a bunch of amateurs!
> I believe there is a proposal to be able to clear the
> shell window. We just need to add "Clear and restart
> shell". There is also an idea to put help output in an
> output window. Undo-ing the result of hitting <enter>
> seems like a sensible extension of undoing the
> So sign the contributor agreement and volunteer to write
> and review patches.
I would be willing to help *IF* i received more thoughtful and
engaging replies like the type you always provide. Thank you
Terry for continuing to be a valuable and welcoming resource
for this community! If not for you and a handful of others,
i would have given up on this community a long time ago.
NOBODY IS GOING TO HELP WHEN THEY GET RESISTANCE!
I will visit the bug tracker again and see if i can provide
some assistance there. Although, the last time i visited, i
remember being annoyed by the tracker interface -- which i
feel is overly noisy and far too complicated. All we need is
a flat list of issues. Is there some method to export
something more "readable"? Or, some sort of documentation?
I must admit, my excitement to help is usually depleted by
the tracker interface before i even have a chance to offer
anything substantial.
If this bug tracker does not improve, i will be forced to
continue posting my grievances here.
--
https://mail.python.org/mailman/listinfo/python-list
