This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: IDLE code completion window can hang or misbehave with mouse
Type: behavior Stage: resolved
Components: IDLE Versions: Python 3.7, Python 3.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: terry.reedy Nosy List: Al.Sweigart, littleq0903, louielu, markroseman, ned.deily, paulsfo, roger.serwy, serhiy.storchaka, suddha.sourav, taleinat, terry.reedy
Priority: normal Keywords:

Created on 2012-08-27 00:35 by suddha.sourav, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 1517 closed louielu, 2017-05-09 13:15
PR 1811 merged louielu, 2017-05-25 09:51
PR 2187 merged terry.reedy, 2017-06-14 15:18
PR 2198 merged terry.reedy, 2017-06-14 19:25
PR 2199 merged terry.reedy, 2017-06-14 19:56
Messages (51)
msg169175 - (view) Author: suddha sourav (suddha.sourav) Date: 2012-08-27 00:34
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.
msg169178 - (view) Author: Colin Su (littleq0903) * Date: 2012-08-27 03:54
On which platform?
msg169191 - (view) Author: suddha sourav (suddha.sourav) Date: 2012-08-27 08:16
Platform is Windows 7 Professional 64-bit. Sorry for not including the information!
msg171842 - (view) Author: suddha sourav (suddha.sourav) Date: 2012-10-03 01:02
I would like to let you know that the issue also persists for Windows 8 Pro
RTM. Has anything been decided on this bug?

On Fri, Aug 31, 2012 at 5:56 PM, Terry J. Reedy <report@bugs.python.org>wrote:

>
> Changes by Terry J. Reedy <tjreedy@udel.edu>:
>
>
> ----------
> nosy: +serwy, terry.reedy
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue15786>
> _______________________________________
>
msg171849 - (view) Author: Roger Serwy (roger.serwy) * (Python committer) Date: 2012-10-03 03:19
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.
msg171880 - (view) Author: suddha sourav (suddha.sourav) Date: 2012-10-03 11:46
Thank you for the hint, Roger! On my side, I have changed the
HIDE_SEQUENCES tuple to ("<Key-Escape>",) and it is giving me the behaviour
I desired. However, I am not sure if this is a fix of the real issue.

I tried IDLE on OpenSUSE 12.2 last night and faced the problem in its other
manifestation, which you describe.

Thank you again tor the quick feedback!
msg220751 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2014-06-16 19:55
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:

1. launch IDLE with an IDLE shell window open
2. open an IDLE edit window for a new file
3. in the edit window, press "a" then "TAB"
4. the code completion window opens as expected
5. using the mouse, click on a selection in the code completion list

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.
msg220785 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-06-17 01:00
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.
msg241368 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2015-04-17 21:31
I closed #23954 in favor of this one.
msg241429 - (view) Author: Al Sweigart (Al.Sweigart) * Date: 2015-04-18 17:09
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):

1. Type "pri"
2. Press Ctrl+Space or click Edit > Show Completions. The autocomplete window appears.
3. Press Tab. The text updates from "pri" to "print"
4. However, the autocomplete window is still there.
5. Pressing space or ( will then cause the autocomplete window to disappear.
msg264921 - (view) Author: paul czyzewski (paulsfo) Date: 2016-05-05 21:08
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.5

Unrelated 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?
msg264926 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-05 23:07
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.
msg264928 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-05-06 01:47
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).
msg264929 - (view) Author: paul czyzewski (paulsfo) Date: 2016-05-06 03:06
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.
msg264962 - (view) Author: suddha sourav (suddha.sourav) Date: 2016-05-06 10:53
I reported the issue in 2012, and it's not nice to see that in four years
the flagship editor of Python in all platforms I know is still something I
have to avoid. I am not writing this mail to vent; I'm asking: what can we
do, and through which channels we can go, for a quick solution? I am
unfamiliar with the structure of issue resolving in Python, maybe Ned can
help?

Thank you all

On Fri, May 6, 2016 at 8:36 AM, paul czyzewski <report@bugs.python.org>
wrote:

>
> paul czyzewski added the comment:
>
> 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.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue15786>
> _______________________________________
>
msg265265 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-10 19:07
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 #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 #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.
msg265446 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-13 05:48
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.
msg265450 - (view) Author: paul czyzewski (paulsfo) Date: 2016-05-13 06:25
> 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?

Hi Terry, 
   It's definitely on button down.  The popup immediately disappears and I'm hung, without ever releasing the mouse button.

  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
msg265456 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2016-05-13 08:56
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...
msg265466 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-13 11:56
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.
msg265488 - (view) Author: paul czyzewski (paulsfo) Date: 2016-05-13 21:05
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.  
  This is still useful but, Tal, I'm just pointing out that I don't see any options disappear (as I think you're saying they should).  Should the list really be visibly filtered?

  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.
   import os
   type "os.g" and wait.
      RESULT: the popup never appears.  It will appear if I then do "cntl-space" but not from a time delay.  This seems like another biggish usability bug.  The time delay should work (as I think you're saying) and obviously "cntl-space" isn't something a newbie is likely to know to try.
msg265490 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-13 21:21
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.
msg265491 - (view) Author: paul czyzewski (paulsfo) Date: 2016-05-13 21:34
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.


>The list is not supposed to shrink. Having everything disappear on a typo would not seem good to me.

   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.
msg265495 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-13 23:19
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).
msg265498 - (view) Author: paul czyzewski (paulsfo) Date: 2016-05-13 23:55
>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
thanks
  Paul
msg270903 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-07-21 02:54
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
LISTUPDATE_SEQUENCE = "<B1-ButtonRelease>"

# 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?
msg272070 - (view) Author: Mark Roseman (markroseman) * Date: 2016-08-05 22:57
I've done some playing around... not quite there yet, but I think much closer.

First, I assume the 'freeze' on Mac is not a hard freeze, but where the text window is not responding to events, but if you switch to another app and back, it works again?

Second, right now (assuming I've got the latest), if you click on the listbox it goes away immediately, due to it being included in HIDE_SEQUENCES (meaning ButtonPress generates <<autocompletewindow-hide>> which calls the routine to hide the autocomplete window. Which obscures any double click event etc. 

Third, and I think this is the key to this, is that all of the event_add, event_delete, bind, and unbind are not calling Tkinter routines directly, but are going through the multicall module (which allows an event to fire more than one binding). When we call hide_window, we're doing several event_delete and unbind  calls in multicall to undo the bindings we had set up before. Which should leave us back where we started, with the text widget bindings still firing when events come in.

So then is it an issue of the events not coming in (indicating a bug in Tkinter or how we're calling it), or multicall not correctly dispatching to the text widget?

Stick a print() call in multicall.py:_ComplexBinder:__create_handler:handler and you'll see the events are being generated by Tk, but multicall isn't dispatching them.

When I get a chance again, I can see about digging into multicall to verify if it is doing something wrong.

I'll also raise a meta-issue, and that is that using a multicall-like wrapper approach may not necessarily be the best approach to doing the multiple dispatch. Adding a new (Tk widget) class to the text widget (via the 'bindtags' command) and then attaching bindings to that class would I suspect be simpler.

And finally, one simplification for the autocomplete window class... the listbox generates a <<ListboxSelect>> virtual event every time its selection changes, so you don't need to bind against all the clicks, arrow keys, etc.
msg293305 - (view) Author: Louie Lu (louielu) * Date: 2017-05-09 13:05
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
hidell <FocusOut event> generated by:  .!listedtoplevel.!frame.text.!toplevel2 focus on:  None
prove <ButtonPress event num=1 x=130 y=390> generated by:  .!listedtoplevel.!frame.text focus on:  .!listedtoplevel.!frame.text

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.
msg293309 - (view) Author: Louie Lu (louielu) * Date: 2017-05-09 13:22
Test PR on MacOS with Tk 5.8.9, when double click on listbox will cause freeze after hide window
msg293339 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-05-09 19:02
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.)
msg293345 - (view) Author: Louie Lu (louielu) * Date: 2017-05-09 20:09
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.
msg293355 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-05-09 22:14
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.
msg293373 - (view) Author: Louie Lu (louielu) * Date: 2017-05-10 03:23
The step after installing newer Tk will require `make clean` and `make` again to let linker link to the recent install version.

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?
msg293376 - (view) Author: Louie Lu (louielu) * Date: 2017-05-10 03:52
@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.
msg293389 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-05-10 08:07
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.
msg293392 - (view) Author: Louie Lu (louielu) * Date: 2017-05-10 08:59
I'm mainly working on Linux, so these problem didn't affect me alot. I did some test on these issue:

#24801: right click works on 5.8.18 AS version.
#24570: calltips work
#25988: wrong issue number (?)
--
#21603: concur with Ned, save as a file from foo to bar will have extension name, though it won't display on dialog when save as'ing.
#22897: work on 3.x
#28928: open file work well on 3.x with 5.8.18
#
msg293474 - (view) Author: Louie Lu (louielu) * Date: 2017-05-11 07:38
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.
msg293598 - (view) Author: Louie Lu (louielu) * Date: 2017-05-13 06:13
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!
msg294461 - (view) Author: Louie Lu (louielu) * Date: 2017-05-25 10:45
PR 1811 fix some bug in condition of hide_event, now it will work on three different platforms. Terry, it will need your review.
msg294736 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-05-30 04:35
Click still causes disappearance with fresh binary on Win10.
msg294745 - (view) Author: Louie Lu (louielu) * Date: 2017-05-30 08:04
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.
msg294766 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-05-30 16:25
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.
msg294805 - (view) Author: Louie Lu (louielu) * Date: 2017-05-31 02:27
I fix this as:

    if not self.autocompletewindow:
        return

I think this another different behavior on different platform. I can't reproduce this on Linux...
msg295979 - (view) Author: Louie Lu (louielu) * Date: 2017-06-14 02:56
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.
msg295980 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-06-14 04:14
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.
msg296011 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-06-14 15:13
New changeset 778b484145edfd0d9b65129322d3295bed8eb71a by terryjreedy (mlouielu) in branch 'master':
bpo-15786: IDLE: Fix mouse clicks on autocompletetion window (#1811)
https://github.com/python/cpython/commit/778b484145edfd0d9b65129322d3295bed8eb71a
msg296013 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-06-14 15:43
New changeset 3280579450e3ee94e4916e2543b4dd8898d51b02 by terryjreedy in branch '3.6':
bpo-15786: IDLE: Fix mouse clicks on autocompletetion window (#1811) (#2187)
https://github.com/python/cpython/commit/3280579450e3ee94e4916e2543b4dd8898d51b02
msg296015 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-06-14 16:36
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, #27609.
Improve autocomplete tests.
Improve 'Completions' doc subsection.
Stop insertion of \n into text when closing box
 (see opening message above).
I will also post a message on #27609 about behavior issues mentioned here that are not part of any open issue.
msg296029 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-06-14 19:43
New changeset 32fd874afe55e396e3c9a5af35e7bb3d8e0b8f02 by terryjreedy in branch 'master':
bpo-15786: Fix IDLE autocomplete return problem. (#2198)
https://github.com/python/cpython/commit/32fd874afe55e396e3c9a5af35e7bb3d8e0b8f02
msg296030 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-06-14 20:10
New changeset 6628006941f4382813a9af4628894c99bb333b8f by terryjreedy in branch '3.6':
[3.6]bpo-15786: Fix IDLE autocomplete return problem. (#2198) (#2199)
https://github.com/python/cpython/commit/6628006941f4382813a9af4628894c99bb333b8f
msg296031 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2017-06-14 20:10
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

>>> re.c<^-space>

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'
History
Date User Action Args
2022-04-11 14:57:35adminsetgithub: 59990
2017-06-14 20:21:06terry.reedyunlinkissue27609 dependencies
2017-06-14 20:10:53terry.reedysetmessages: + msg296031
2017-06-14 20:10:13terry.reedysetmessages: + msg296030
2017-06-14 19:56:54terry.reedysetpull_requests: + pull_request2243
2017-06-14 19:43:18terry.reedysetmessages: + msg296029
2017-06-14 19:25:13terry.reedysetpull_requests: + pull_request2242
2017-06-14 16:36:38terry.reedysetstatus: open -> closed
versions: - Python 2.7, Python 3.5
messages: + msg296015

resolution: fixed
stage: test needed -> resolved
2017-06-14 15:43:51terry.reedysetmessages: + msg296013
2017-06-14 15:18:45terry.reedysetpull_requests: + pull_request2236
2017-06-14 15:13:50terry.reedysetmessages: + msg296011
2017-06-14 04:14:23terry.reedysetmessages: + msg295980
2017-06-14 02:56:14louielusetmessages: + msg295979
2017-05-31 02:27:00louielusetmessages: + msg294805
2017-05-30 16:25:45terry.reedysetmessages: + msg294766
2017-05-30 08:04:11louielusetmessages: + msg294745
2017-05-30 04:35:24terry.reedysetmessages: + msg294736
2017-05-25 10:45:27louielusetmessages: + msg294461
versions: + Python 3.7
2017-05-25 09:51:16louielusetpull_requests: + pull_request1897
2017-05-13 06:13:30louielusetmessages: + msg293598
2017-05-11 07:38:51louielusetmessages: + msg293474
2017-05-10 08:59:02louielusetmessages: + msg293392
2017-05-10 08:07:19terry.reedysetmessages: + msg293389
2017-05-10 03:52:16louielusetmessages: + msg293376
2017-05-10 03:23:42louielusetmessages: + msg293373
2017-05-09 22:14:59terry.reedysetassignee: terry.reedy
messages: + msg293355
2017-05-09 20:09:48louielusetmessages: + msg293345
2017-05-09 19:02:00terry.reedysetmessages: + msg293339
2017-05-09 13:22:53louielusetmessages: + msg293309
2017-05-09 13:15:08louielusetpull_requests: + pull_request1617
2017-05-09 13:05:22louielusetnosy: + louielu
messages: + msg293305
2016-08-05 22:57:03markrosemansetnosy: + markroseman
messages: + msg272070
2016-07-25 00:08:07terry.reedylinkissue27609 dependencies
2016-07-21 02:54:50terry.reedysetnosy: + serhiy.storchaka
messages: + msg270903
2016-05-13 23:55:53paulsfosetmessages: + msg265498
2016-05-13 23:19:06terry.reedysetmessages: + msg265495
2016-05-13 21:34:00paulsfosetmessages: + msg265491
2016-05-13 21:21:00terry.reedysetmessages: + msg265490
2016-05-13 21:05:19paulsfosetmessages: + msg265488
2016-05-13 11:56:54terry.reedysetmessages: + msg265466
2016-05-13 08:56:35taleinatsetmessages: + msg265456
2016-05-13 06:25:00paulsfosetmessages: + msg265450
2016-05-13 05:48:16terry.reedysetmessages: + msg265446
2016-05-10 19:07:34terry.reedysetmessages: + msg265265
2016-05-06 10:53:50suddha.souravsetmessages: + msg264962
2016-05-06 03:06:42paulsfosetmessages: + msg264929
2016-05-06 01:47:37ned.deilysetmessages: + msg264928
2016-05-05 23:07:57terry.reedysetmessages: + msg264926
versions: + Python 3.6, - Python 3.4
2016-05-05 21:08:55paulsfosetnosy: + paulsfo
messages: + msg264921
2016-04-25 03:54:14berker.peksaglinkissue23961 superseder
2015-04-18 17:09:16Al.Sweigartsetmessages: + msg241429
2015-04-17 21:33:30Al.Sweigartsetnosy: + Al.Sweigart
2015-04-17 21:31:53terry.reedysetmessages: + msg241368
2015-04-17 21:31:21terry.reedylinkissue23954 superseder
2014-06-17 01:00:10terry.reedysetnosy: + taleinat

messages: + msg220785
stage: needs patch -> test needed
2014-06-16 19:55:13ned.deilysetnosy: + ned.deily
title: IDLE code completion window does not scroll/select with mouse -> IDLE code completion window can hang or misbehave with mouse
messages: + msg220751

versions: + Python 3.5, - Python 3.3
2013-06-15 19:08:00terry.reedysetversions: - Python 3.2
2012-10-03 13:57:35serhiy.storchakasettitle: IDLE code completion window does not scoll/select with mouse -> IDLE code completion window does not scroll/select with mouse
2012-10-03 11:46:04suddha.souravsetmessages: + msg171880
2012-10-03 03:19:04roger.serwysettype: behavior
stage: needs patch
messages: + msg171849
versions: + Python 3.2, Python 3.3, Python 3.4
2012-10-03 01:03:00suddha.souravsetmessages: + msg171842
2012-09-01 00:56:15terry.reedysetnosy: + terry.reedy, roger.serwy
2012-08-27 08:16:36suddha.souravsetmessages: + msg169191
2012-08-27 03:54:37littleq0903setnosy: + littleq0903
messages: + msg169178
2012-08-27 00:35:00suddha.souravcreate