Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IDLE code completion window can hang or misbehave with mouse #59990

Closed
suddhasourav mannequin opened this issue Aug 27, 2012 · 51 comments
Closed

IDLE code completion window can hang or misbehave with mouse #59990

suddhasourav mannequin opened this issue Aug 27, 2012 · 51 comments
Assignees
Labels
3.7 expert-IDLE type-bug

Comments

@suddhasourav
Copy link
Mannequin

@suddhasourav suddhasourav mannequin commented Aug 27, 2012

BPO 15786
Nosy @terryjreedy, @taleinat, @ned-deily, @serwy, @roseman, @serhiy-storchaka, @mlouielu
PRs
  • #1517
  • #1811
  • #2187
  • #2198
  • #2199
  • 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:

    assignee = 'https://github.com/terryjreedy'
    closed_at = <Date 2017-06-14.16:36:38.718>
    created_at = <Date 2012-08-27.00:35:00.748>
    labels = ['expert-IDLE', 'type-bug', '3.7']
    title = 'IDLE code completion window can hang or misbehave with mouse'
    updated_at = <Date 2017-06-14.20:10:53.229>
    user = 'https://bugs.python.org/suddhasourav'

    bugs.python.org fields:

    activity = <Date 2017-06-14.20:10:53.229>
    actor = 'terry.reedy'
    assignee = 'terry.reedy'
    closed = True
    closed_date = <Date 2017-06-14.16:36:38.718>
    closer = 'terry.reedy'
    components = ['IDLE']
    creation = <Date 2012-08-27.00:35:00.748>
    creator = 'suddha.sourav'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 15786
    keywords = []
    message_count = 51.0
    messages = ['169175', '169178', '169191', '171842', '171849', '171880', '220751', '220785', '241368', '241429', '264921', '264926', '264928', '264929', '264962', '265265', '265446', '265450', '265456', '265466', '265488', '265490', '265491', '265495', '265498', '270903', '272070', '293305', '293309', '293339', '293345', '293355', '293373', '293376', '293389', '293392', '293474', '293598', '294461', '294736', '294745', '294766', '294805', '295979', '295980', '296011', '296013', '296015', '296029', '296030', '296031']
    nosy_count = 11.0
    nosy_names = ['terry.reedy', 'taleinat', 'ned.deily', 'roger.serwy', 'markroseman', 'Al.Sweigart', 'serhiy.storchaka', 'littleq0903', 'suddha.sourav', 'paulsfo', 'louielu']
    pr_nums = ['1517', '1811', '2187', '2198', '2199']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue15786'
    versions = ['Python 3.6', 'Python 3.7']

    @suddhasourav
    Copy link
    Mannequin Author

    @suddhasourav suddhasourav mannequin commented Aug 27, 2012

    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.

    @suddhasourav suddhasourav mannequin added the expert-IDLE label Aug 27, 2012
    @littleq0903
    Copy link
    Mannequin

    @littleq0903 littleq0903 mannequin commented Aug 27, 2012

    On which platform?

    @suddhasourav
    Copy link
    Mannequin Author

    @suddhasourav suddhasourav mannequin commented Aug 27, 2012

    Platform is Windows 7 Professional 64-bit. Sorry for not including the information!

    @suddhasourav
    Copy link
    Mannequin Author

    @suddhasourav suddhasourav mannequin commented Oct 3, 2012

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


    @serwy
    Copy link
    Mannequin

    @serwy serwy mannequin commented Oct 3, 2012

    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.

    @serwy serwy mannequin added the type-bug label Oct 3, 2012
    @suddhasourav
    Copy link
    Mannequin Author

    @suddhasourav suddhasourav mannequin commented Oct 3, 2012

    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!

    @serhiy-storchaka serhiy-storchaka changed the title IDLE code completion window does not scoll/select with mouse IDLE code completion window does not scroll/select with mouse Oct 3, 2012
    @ned-deily
    Copy link
    Member

    @ned-deily ned-deily commented Jun 16, 2014

    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.

    @ned-deily ned-deily changed the title IDLE code completion window does not scroll/select with mouse IDLE code completion window can hang or misbehave with mouse Jun 16, 2014
    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented Jun 17, 2014

    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.

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented Apr 17, 2015

    I closed bpo-23954 in favor of this one.

    @AlSweigart
    Copy link
    Mannequin

    @AlSweigart AlSweigart mannequin commented Apr 18, 2015

    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.

    @paulsfo
    Copy link
    Mannequin

    @paulsfo paulsfo mannequin commented May 5, 2016

    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?

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 5, 2016

    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.

    @ned-deily
    Copy link
    Member

    @ned-deily ned-deily commented May 6, 2016

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

    @paulsfo
    Copy link
    Mannequin

    @paulsfo paulsfo mannequin commented May 6, 2016

    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.

    @suddhasourav
    Copy link
    Mannequin Author

    @suddhasourav suddhasourav mannequin commented May 6, 2016

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


    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 10, 2016

    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.

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 13, 2016

    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.

    @paulsfo
    Copy link
    Mannequin

    @paulsfo paulsfo mannequin commented May 13, 2016

    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

    @taleinat
    Copy link
    Contributor

    @taleinat taleinat commented May 13, 2016

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

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 13, 2016

    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.

    @paulsfo
    Copy link
    Mannequin

    @paulsfo paulsfo mannequin commented May 13, 2016

    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.

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 13, 2016

    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.

    @paulsfo
    Copy link
    Mannequin

    @paulsfo paulsfo mannequin commented May 13, 2016

    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.

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 13, 2016

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

    @paulsfo
    Copy link
    Mannequin

    @paulsfo paulsfo mannequin commented May 13, 2016

    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

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented Jul 21, 2016

    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?

    @roseman
    Copy link
    Mannequin

    @roseman roseman mannequin commented Aug 5, 2016

    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.

    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented May 9, 2017

    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.

    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented May 9, 2017

    Test PR on MacOS with Tk 5.8.9, when double click on listbox will cause freeze after hide window

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 9, 2017

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

    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented May 9, 2017

    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.

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 9, 2017

    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.

    @terryjreedy terryjreedy self-assigned this May 9, 2017
    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented May 10, 2017

    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?

    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented May 10, 2017

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

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 10, 2017

    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.

    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented May 10, 2017

    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.
    bpo-24570: calltips work
    bpo-25988: wrong issue number (?)

    bpo-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.
    bpo-22897: work on 3.x
    bpo-28928: open file work well on 3.x with 5.8.18

    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented May 11, 2017

    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.

    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented May 13, 2017

    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!

    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented May 25, 2017

    PR 1811 fix some bug in condition of hide_event, now it will work on three different platforms. Terry, it will need your review.

    @mlouielu mlouielu mannequin added the 3.7 label May 25, 2017
    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 30, 2017

    Click still causes disappearance with fresh binary on Win10.

    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented May 30, 2017

    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.

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented May 30, 2017

    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.

    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented May 31, 2017

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

    @mlouielu
    Copy link
    Mannequin

    @mlouielu mlouielu mannequin commented Jun 14, 2017

    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.

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented Jun 14, 2017

    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.

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented Jun 14, 2017

    New changeset 778b484 by terryjreedy (mlouielu) in branch 'master':
    bpo-15786: IDLE: Fix mouse clicks on autocompletetion window (bpo-1811)
    778b484

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented Jun 14, 2017

    New changeset 3280579 by terryjreedy in branch '3.6':
    bpo-15786: IDLE: Fix mouse clicks on autocompletetion window (bpo-1811) (bpo-2187)
    3280579

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented Jun 14, 2017

    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.
    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 bpo-27609 about behavior issues mentioned here that are not part of any open issue.

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented Jun 14, 2017

    New changeset 32fd874 by terryjreedy in branch 'master':
    bpo-15786: Fix IDLE autocomplete return problem. (bpo-2198)
    32fd874

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented Jun 14, 2017

    New changeset 6628006 by terryjreedy in branch '3.6':
    [3.6]bpo-15786: Fix IDLE autocomplete return problem. (bpo-2198) (bpo-2199)
    6628006

    @terryjreedy
    Copy link
    Member

    @terryjreedy terryjreedy commented Jun 14, 2017

    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'

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.7 expert-IDLE type-bug
    Projects
    None yet
    Development

    No branches or pull requests

    3 participants