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
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>
> _______________________________________
>

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
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!

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.

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 #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):

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.

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?

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
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>
> _______________________________________
>

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.

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.

> 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

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.  
  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.

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.


>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.

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).

>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

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?

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.

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.

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 `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?

@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:

#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
#

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:
        return

I 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.

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

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

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.

New changeset 32fd874afe55e396e3c9a5af35e7bb3d8e0b8f02 by terryjreedy in branch 'master':
bpo-15786: Fix IDLE autocomplete return problem. (#2198)
https://github.com/python/cpython/commit/32fd874afe55e396e3c9a5af35e7bb3d8e0b8f02

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

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'