IDLE code completion window can hang or misbehave with mouse or <return> #59990
Comments
|
In IDLE, pressing tab brings up the code completion menu - however, the scrollbar, when clicked, does not scroll - it disappears. Same goes for clicking an option in the code completion widget - it disappears. Keyboard navigation (pgup/pgdown/up/down) and tab works. In addition, pressing enter does not autocomplete but execute what was meant to be selected. |
|
On which platform? |
|
Platform is Windows 7 Professional 64-bit. Sorry for not including the information! |
|
I would like to let you know that the issue also persists for Windows 8 Pro On Fri, Aug 31, 2012 at 5:56 PM, Terry J. Reedy <report@bugs.python.org>wrote:
|
|
I can confirm that the existing behavior of IDLE prohibits clicking on the scroll bar on Windows (but not Linux). Clicking on an item in the window closes it without actually selecting the clicked item. This is true on both Windows and Linux. On Windows, the <FocusOut> event is generated when selecting the completion window, causing it to close. On Linux with Gnome3.4, the scroll bar is clickable without closing the window. By removing "<FocusOut>" from HIDE_SEQUENCES in AutoCompleteWindow.py, the completion window can now take focus. However, the completion window will need some work since key presses in the focused window doesn't change the text selection. |
|
Thank you for the hint, Roger! On my side, I have changed the I tried IDLE on OpenSUSE 12.2 last night and faced the problem in its other Thank you again tor the quick feedback! |
serhiy-storchaka
changed the title
|
Investigating a user report of IDLE freezing on OS X when mouse clicking on the code completion menu led me to this issue. The behavior I see varies depending on the Tk variant in use. The basic test case is:
With two different X11 Tk's (Debian Linux 8.5.x and OS X X11 8.6.x), clicking on the selection causes the code completion window to disappear but the code completion text does not appear in the edit window. Further, then pressing "Return", "a", and "Tab" to try a new code completion results in the code completion window momentarily appearing then disappearing. If one uses the mouse to click on and change focus to another IDLE window (e.g. the shell window), then click on and return focus to the edit window, the code completion window starts working again, at least, until using the mouse to click on a selection again. With the current Cocoa Tk 8.5.x on OS X (the most commonly used Tk there), the behavior is even more confusing to the user. After mouse-clicking on a code completion menu item, the code completion menu disappears but then the edit window becomes unresponsive to either the keyboard or the mouse until focus is moved, again by clicking on another IDLE window and then returning to the "hung" edit window. Oddly enough, the older Carbon Tk 8.4.x on OS X (used with 32-bit-only Pythons) seems to handle this all correctly. I did not try this with a Windows Tk. I also did not systematically check all current versions of IDLE with all of those Tk variants but spot checking saw similar behavior on current dev (pre-3.5), 3.4.1, and 2.7.x. |
ned-deily
changed the title
|
Idle Help, Completion sections "Two tabs in a row will supply the current ACW selection, as will return or a double click." On 3.4 windows, tab-tab works, one click dismisses the box immediately but without disabling it. Contrary to the claim above, <return> dismisses the box with no entry and enters <return> into the window (shell or editor). <space> on the other hand, does the same as tab-tab + enters a space. I actually like this better than return, but the doc and behavior should match and the widget never become disabled. The doc does not say anything about navigation. I recently committed an *incomplete* test_autocomplete from one of last summer's GSOC students, but it obviously does not test what really needs to be tested. |
|
I closed bpo-23954 in favor of this one. |
|
Additionally, pressing tab after the autocomplete window has appeared should not just update the text but also close the autocomplete window. The repro steps are (on Windows 7 64-bit, Python 3.5):
|
|
I'm new to IDLE. I just upgraded to Mac El Capitan from Snow Leopard, and installed Python 3.5.1 (v3.5.1:37a07cee5969, Dec 5 2015, 21:12:44). I have had the IDLE window freeze so many times (when clicking on something in the autocomplete window as described by Ned Deily) that I consider IDLE unusable. I'm not familiar with Python bug practices but I would consider this a serious bug because, as a product manager would probably put it, this is going to drive away a significant percentage of new users (i.e., unexplained freezing of the product when doing something which seems natural -- clicking on the item that I want to select). BTW, looks like I'm on tcl 8.5:
>>> tkinter.TclVersion
8.5Unrelated question: which can't Mac Spotlight find tkinter.py? is it in some compressed file or something, so I can't find a standalone py file? |
|
As far as I know, freezing is limited to Macs. In msg220751, Ned said "Further, then pressing "Return", "a", and "Tab" to try a new code completion results in the code completion window momentarily appearing then disappearing." The disappearance , and hence the later reappearance Ned describes, does not happen for me on Windows. In my view, AutoComplete.py and AutoCompleteWindow.py need to be combined, refactored, re-written, and tested on all systems with a much more complete test suite. |
|
Paul, also check to make sure you have installed the latest ActiveTcl Tcl/Tk 8.5.x (not 8.6.x) as described here: https://www.python.org/download/mac/tcltk/. One way to tell exactly which minor release of Tcl/Tk (the "x" in "8.5.x") is in use is to click on the "About IDLE" menu item in the "IDLE" menu or, depending on how you launched IDLE, "About Python" in the "Python" menu. It should be 8.5.18 or higher and not 8.5.9 (the Apple-supplied version). |
|
Thanks, Terry and Ned. Ned, I checked (nice clear instructions, btw) and I had Tk 8.5.10. So I followed the link and installed 8.5.18. -- The freeze on mac still occurs but I understand that this will avoid some other bugs. BTW, I don't know how testing works for IDLE and Python, but that's what I do for a living, so maybe I'll try to get involved. |
|
I reported the issue in 2012, and it's not nice to see that in four years Thank you all On Fri, May 6, 2016 at 8:36 AM, paul czyzewski <report@bugs.python.org>
|
|
Suddha: Someone has to write a currently failing test and a patch that makes it pass without breaking anything else. I cannot currently test this issue and therefore cannot currently patch it. AutoComplete has numerous other issues that I can test. About a month ago, I reviewed the code with an eye to fixing them. I decided what I implied above, which is that I should not do anything until I can freely modify the code. I just filed bpo-26993 to make that possible. Paul: For testing CPython in general, see https://docs.python.org/devguide/, chapter 4 and 5 (and the unittest docs). For testing IDLE, see test/test_idle and idlelib/idle_test, in particular README and htest.py. The latter is specific to IDLE. If bpo-26993 is approved, we will need LOTS of new tests for IDLE, as I want to properly follow the *written* failing test, write patch, passing test paradigm. |
|
I experimented more with 3.5.1, Win 10 and formulated a question and hypothesis. In a text widget, pressing button 1 (usually the left) moves the cursor to the nearest between-character slice line. Hold the button down allows selecting text. Releasing and pressing again selects a word after moving the cursor. Pretty standard behavior, independent of IDLE. I believe the bindings are Text class rather than instance bindings. When a completion box is present, button 1 down outside the box dismiss the box and moves the cursor. I believe this is intended. I don't know how general this behavior is. The IDLE completion box binds the button *release* to, I believe, "move cursor to line clicked and display line in text". A double click is supposed to do something more. So the button1 press event goes to the Text, which dismisses the popup and moves the cursor. Question: does the text widget freezes on button down or not until button up. The experiment is to press and hold the button while moving the mouse. Does the cursor move and select text while the button is down, or does it freeze immediately. Paul, could you try this? Hypothesis (cause): a delicate timing issue? Is the button-up event somehow 'half-caught'? Hypothesis (fix): prevent the text from seeing or acting on the button down event. It should be possible to have the completion box catch the down event first and return 'break'. My first attempt failed but I was too tired to continue. |
Hi Terry, Newbie question: what is the "normal" way to use this feature. I see that it apparently only works when I'm at the dot (eg, at op. ). So,if I want op.getcwd, I have to scroll a *long* way to get to it (rather than, eg, tyep op.g or whatever) and then, when op.getcwd shows (below the box), I need to type "()" and hit return. this seems a bit painful. Is that the best use of this feature? Paul |
|
Regarding your questions about completion behavior: You don't have to scroll, you can continue typing and the completion list will filter itself to options that match the additional characters. Deleting characters works too (options reappear in the list). The second thing you mention is having to manually type the parenthesis after completing a function/method name. A long time ago, I had a prototype which added them automatically, but I never got it polished enough to add to IDLE. However, this has rarely been raised as a request. Also, Terry said he wants to refactor the code and get it well tested, so I imagine new features like this won't get in any time soon... |
|
Thanks Paul, that will probably be helpful somehow. I was expecting the opposite. Hmmmm. Box comes up after cntl-space or time delay after key char. I have time delay much shorter than default. I do what Tal said -- type a couple of letters, then sometimes use down arrow key, I guess I learned years ago not to click, and had forgotten, so I seldom have a problem. But I completely understand that a new user could get very upset. |
|
hi Tal and Terry, I hadn't noticed that continuing to type does go to the appropriate spot. However, I see what I think are two or three bugs (not sure is 'a)' is a bug) in the behavior: a) on my system it does not visibly filter the list. EG, if I type 'os.', wait for the popup, then type ge (so, 'os.ge') it scrolls down to, and selects, "get_blocking", but the rest of the list is still there. b) say I want os.get_terminal_size. I type "os." and wait for the popup to appear (see 'c)' for why this is necessary); then I type 'get_t". Now "get_terminal_size" is visible and selected but autocompletion doesn't occur. I.E., I still have 'os.get_t" below the popup. To get the full word I have to arrow *away* from the correct answer and then arrow back to it. Now "get_terminal_size" appears below the popup. This is obviously less serious, and less mysterious, than the original hang issue, but it's still a usability issue. c) Terry: regarding "Box comes up after cntl-space or time delay after key char." On my IDLE, the box *never* appears if I initially type beyond the ".". E.G. |
|
The time delay and popup is only after a key letter, like '.' or '"'. Having the box appear whenever one pauses would be maddening. I have the delay set to .1 second. The list is not supposed to shrink. Having everything disappear on a typo would not seem good to me. But it might be possible to visually separate remaining possibilities, so when only one option (or none) is left, it is visually obvious. Once the overt bugs are fixed, it would not hurt to review details of intended behavior, perhaps with some review of other completers. |
|
hi Terry, thanks for all the responses. Well, what *I* found maddening was that typing "os." pause "g" works but typing "os.g" (with no pause) does nothing. :) But, anyway, I guess you're saying that that's as designed.
Actually, I think that many widgets do work that way, but I think that, here, I agree with you, since the user might notice a nearby entry which is what they wanted. What about my "b)" (copied just below)? Is there a reason not to autocomplete what's on the command line, as is done if you *arrow* to a selection? Again, not nearly as big an issue as the original hang but I can't think of a reason not to autocomplete in this case, and the code to do so must already exist. b) say I want os.get_terminal_size. I type "os." and wait for the popup to appear (see 'c)' for why this is necessary); then I type 'get_t". Now "get_terminal_size" is visible and selected but autocompletion doesn't occur. I.E., I still have 'os.get_t" below the popup. To get the full word I have to arrow *away* from the correct answer and then arrow back to it. Now "get_terminal_size" appears below the popup. This is obviously less serious, and less mysterious, than the original hang issue, but it's still a usability issue. |
|
When the correct item is highlighted, hit tab once to copy it to the text, hit tab a second time to close the box. If you use the arrow keys to select and copy as you go, you still have to hit tab twice to close the box (or click elsewhere). |
Not for me. If i use arrow keys then I just type "()" and the box disappears. So there's two(?) fewer keystrokes needed if you use the arrow keys. But anyway, I'll quit looking for additional minor bugs in this thread. :D |
|
Serhiy, could you take at least a quick look at this troublesome issue? The issue seems to be this: idlelib.autocomplete_w.py has # at the top # within show_window method
self.listupdateid = listbox.bind(LISTUPDATE_SEQUENCE,
self.listselect_event)
# and later
def listselect_event(self, event):However, when one clicks on a completion box, the click is only seen by the text window underneath, and the box disappears. On Mac, there are also nasty symptoms like IDLE freezing. I that changing the sequence to '<Button-1>' and addint 'return "break"' to the end of listselect_event might solve the problem. When it did not, I added prints to the top of __init__ and listselect_event. Running in the console, the first printed, the second did not. Do you have any idea why not? |
|
The reason why click on listbox will disappear is because we bind HIDE_VIRTUAL_EVENT with <focusOut> on widget.text. When click on listbox, it will focusOut the widget.text then focusOn listbox, thus trigger the hide process. The reason why click on listbox and move the cursor out of box, then click will freeze IDLE cursor, it because tk will generate three event: FocusOut, FocusOut, and ButtonPress: hidell <FocusOut event> generated by: .!listedtoplevel.!frame.text.!toplevel2.!listbox focus on: None Becase we bind HIDE process on widget.text, it will then trigger hide_window, and at the same time, FoucsOut event is still on the half-way, and then the listbox is destory and reset to None, I think this is why it will freeze until re-focus on IDEL. Attach PR solve this problem, it re-bind the HIDE process from widget.text to listbox, thus it will not trigger some race-contidion when destroying autocompletewindow. |
|
Test PR on MacOS with Tk 5.8.9, when double click on listbox will cause freeze after hide window |
|
While 8.5.9 on OSX is more usable than 8.5.7, it is known to crash occasionally. Hence the startup warning. See idlelib.macosx.tkVersionWarning and https://www.python.org/download/mac/tcltk/. (The problems listed in the latter for 8.5.9 seems incomplete ;-). So I am not greatly concerned about another one specific to Apple 8.5.9. runscript.Script_binding.run_module_event has a workaround, a 200 millesecond delay, when one uses F5 instead of the menu. Would that work here? (editor.get_accelerator has a different workaround for other keys.) |
|
There is a difference between Linux and Mac freeze. On linux, if freeze and I insert pdb.set_trace() at the end of the hide_window, it will let cursor blink again, while on Mac, this won't work. I try self.widget.after(200, self.hide_window) and it doesn't work, too. I install Tk 8.5.18 as the web recommand, should I need to reboot or chnage the default path? it still bump out the warning that I'm using 8.5.9 instead. |
|
I would try rebooting, but not having a Mac, I am not familiar with the details of the instructions on that page. It they are not clear enough, they should be improved. |
|
The step after installing newer Tk will require I can freeze the cursor after double click on any version of Tk I install, 8.5.9 / 8.5.18 / 8.6.4 on MacOS Sierra. Maybe we should separate this problem, let this issue focus on fixing misbehavior of listbox, and create another for MacOS freeze issue? |
|
@terry, this is another too-fast-to-destroy problem. The latest PR commit has fixed the issue on MacOS. When we double click on autocompletewindow, it will try to focusOut autocompletewindow then focusOn widget.text, but, we destroy too fast, after destroy, tk can't re-focusOn widget.text. The commit will re-focus on widget.text first, then destroy the autocompletewindow. |
|
Some existing idle-macosx issues are 17060 and 18444 (possibly dups), 24570, 24801, 25988 (dup of this?), 21603, 22897, 28928. (At least 1 might be closed). If none of these cover issue you have in mind, please go ahead. |
|
I'm mainly working on Linux, so these problem didn't affect me alot. I did some test on these issue: bpo-24801: right click works on 5.8.18 AS version.
|
|
Additional info for Windows platform: when creating autocompletewindow, it will bind "<Configure>" to winconfig, this cause a problem, when showing up the acw, it will misbehavior calling multiple times about <Configure>. The result is, tk will not able to response to Double-ButtonRelease. |
|
Terry, the latest PR fix the problem both on Linux / MacOS and Windows, please help to review and test if there is any problem on different platform, thanks! |
|
PR 1811 fix some bug in condition of hide_event, now it will work on three different platforms. Terry, it will need your review. |
|
Click still causes disappearance with fresh binary on Win10. |
|
Fix on Windows platform, the behavior was different on Linux and Windows when calling acw.focus_get(), it will need to delay to get the correct focus. |
|
Almost there. Clicking on a list item or the scrollbar works to select an item or scroll. Clicking outside the box *before* clicking elsewhere works to dismiss box. Clicking outside the box *after* clicking inside dismisses the box, but also results in the following, printed twice. Exception in Tkinter callback
Traceback (most recent call last):
File "F:\dev\cpython\lib\tkinter\__init__.py", line 1699, in __call__
return self.func(*args)
File "F:\dev\cpython\lib\tkinter\__init__.py", line 745, in callit
func(*args)
File "F:\dev\cpython\lib\idlelib\autocomplete_w.py", line 257, in _hide_event_check
if not self.autocompletewindow.focus_get():
AttributeError: 'NoneType' object has no attribute 'focus_get'The immediate fix is to catch AttributeError or, perhaps better, wrap the body of _hide_event_check with "if self.autocompletewindow:". There should be no need to hide the window if it is already gone. I am puzzled as to why clicking in the box affects later clicks outside the box. |
|
I fix this as: if not self.autocompletewindow:
returnI think this another different behavior on different platform. I can't reproduce this on Linux... |
|
Terry, would you like to verify the fixed? I think it will be good if this fix can be backported in 3.6 before 3.6.2 released. |
|
Now that I know how to backport with confidence, and have cleared the backlog, and synched 3.6 with 3.7, I want to review this next. I would like to get it in 6.2, but 6.2 was due yesterday, but delayed, and there is no info on how long the delay is. This may be one of the harder patches to review and test, but I will try tomorrow. (Its midnight here now.) My main concern is that we not break one thing while fixing another, which I have done before, due to inadequate tests. I will try to develop a test protocol from doc subsection 2.2 Completions to list what works without the patch. |
|
After hand-testing everything I could think of, including clicking outside the box after clicking inside, I applied the click (and Mac crash) fix to 3.7 and 3.6. As far as I know, it should appear in 3.6.2rc whenever that appears. If so, I hope people who verified the bug will download and try to verify the fix. I will open separate issues for the following and list them on the autocompletions master issue, bpo-27609. |
|
With the severe click bug apparently fixed, I focused on Suddha Sourav last sentence "In addition, pressing enter does not autocomplete but execute what was meant to be selected." In current freshly started IDLE, for example
brings up a box with [compile] highlighted. On hitting <Return> one sees >>> re.c
...
NameError: name 're' is not defined
'c' has not been completed to 'compile' and \n has been inserted into the Text widget, causing the line (in the shell) to be compiled and executed. I imagine that everyone would prefer ">>> re.compile" with the cursor at the end. The fix is so simple that I decided to include it here, today. In autocomplete_w.AutoCompleteWindow.keypress_event, change
elif keysym == "Return":
self.hide_window()
return None
to
elif keysym == "Return":
self.complete()
self.hide_window()
return 'break' |
terryjreedy
changed the title
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: