[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:


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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
pull_requests: +2243

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:


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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
pull_requests: +2242

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:


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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
pull_requests: +2236

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:


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


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

Click still causes disappearance with fresh binary on Win10.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

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

--
versions: +Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Changes by Louie Lu :


--
pull_requests: +1897

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

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!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

Additional info for Windows platform: when creating autocompletewindow, it will 
bind "" to winconfig, this cause a problem, when showing up the acw, 
it will misbehavior calling multiple times about .

The result is, tk will not able to response to Double-ButtonRelease.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

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
#

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--
assignee:  -> terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Changes by Louie Lu :


--
pull_requests: +1617

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Louie Lu]

Louie Lu added the comment:

The reason why click on listbox will disappear is because we bind 
HIDE_VIRTUAL_EVENT with  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  generated by:  
.!listedtoplevel.!frame.text.!toplevel2.!listbox focus on:  None
hidell  generated by:  .!listedtoplevel.!frame.text.!toplevel2 
focus on:  None
prove  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.

--
nosy: +louielu

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Mark Roseman]

Mark Roseman added the comment:

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 <> 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 <> virtual event every time its selection 
changes, so you don't need to bind against all the clicks, arrow keys, etc.

--
nosy: +markroseman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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 = ""

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

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[paul czyzewski]

paul czyzewski added the comment:

>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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[paul czyzewski]

paul czyzewski added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[paul czyzewski]

paul czyzewski added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

Thanks Paul, that will probably be helpful somehow.  I was expecting the 
opposite.  H.

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Tal Einat]

Tal Einat added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[paul czyzewski]

paul czyzewski added the comment:

> 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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[suddha sourav]

suddha sourav added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[paul czyzewski]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Ned Deily]

Ned Deily added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--
versions: +Python 3.6 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[paul czyzewski]

paul czyzewski added the comment:

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?

--
nosy: +paulsfo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Al Sweigart]

Al Sweigart added the comment:

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15786
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Al Sweigart]

Changes by Al Sweigart asweig...@gmail.com:


--
nosy: +Al.Sweigart

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15786
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

I closed #23954 in favor of this one.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15786
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Ned Deily]

Ned Deily added the comment:

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.

--
nosy: +ned.deily
title: IDLE code completion window does not scroll/select with mouse - IDLE 
code completion window can hang or misbehave with mouse
versions: +Python 3.5 -Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15786
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15786] IDLE code completion window can hang or misbehave with mouse

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--
nosy: +taleinat
stage: needs patch - test needed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15786
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com