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

classification
Title: Selection in IDLE often skips first character
Type: behavior Stage: resolved
Components: IDLE, macOS Versions: Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: jungreis, ned.deily, ronaldoussoren
Priority: low Keywords:

Created on 2012-12-24 18:32 by jungreis, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
IMG_1194.MOV jungreis, 2012-12-25 16:11 Short video demonstrating the odd behavior (listen for the mouse clicks).
IMG_1219.MOV jungreis, 2013-01-26 03:54 Short video demonstrating the problem after installing Active Tkl 8.5.13
Messages (7)
msg178088 - (view) Author: Irwin Jungreis (jungreis) Date: 2012-12-24 18:32
Often, when selecting text in IDLE, the first character of the selected region does not get selected. The problem occurs because sometimes, not always, when clicking on the left half of a character the insertion point gets put after the character, while other times it gets put before the character, even when clicking in the exact same spot. This can be consistently reproduced as follows. In IDLE, File | New Window. In the new window type the two characters 'M1' (without the quotes). Now position the cursor over the left half of the M. Slowly click several times without moving the cursor (with enough delay that it does not interpret it as a double-click). Note that after some clicks the insertion point is before the M and after others it is after the M, even though the cursor has not moved.

I am running Python 2.7.3, IDLE version 2.7.3, Tk version 8.5, on Mac OS X 10.6.8 Snow Leopard, on a MacBook Pro. (Same problem occurs on laptop screen and external monitor, and with USB mouse or built in trackpad)
msg178113 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2012-12-25 08:03
Sorry, I'm not able to reproduce the behavior you report, either using a current OS X 10.8.2 system with python.org 2.7.3 and ActiveTcl 8.5.13 or on a virtual 10.6.8 system with an 8.5.12 ActiveTcl.  That said, such behavior would almost certainly be due to behavior within Tk or OS X rather than IDLE or Python itself.  It might also depend on what font and font size you are using and on OS X extension programs you might have installed.  Or on one or more System Preferences settings like input method.  Since there are so many variables, it can be very difficult to isolate exactly what difference is significant in such cases.

Just to be sure, exactly which version of Tk 8.5 are you using with this IDLE?  Assuming you have a version of Xcode command line tools installed, type the following commands in the IDLE shell window:

import Tkinter, subprocess, _tkinter
Tkinter.Tcl().eval('info patchlevel')
print(subprocess.check_output(["otool", "-L", _tkinter.__file__]))
msg178143 - (view) Author: Irwin Jungreis (jungreis) Date: 2012-12-25 16:11
The output of the commands you suggested is below. I've attached a short video showing the problem (listen for the mouse clicks). I also tried with a variety of fonts (proportional and fixed) and font sizes, both bold and not bold, and all had the same problem. (Set a large font size to make the problem easier to reproduce.) I don't think I have changed any settings in Universal Access, and can't think of any extensions that are related. I probably have changed Mouse settings like Tracking Speed, but since the problem occurs using the mouse and the trackpad it seems unlikely to be due to settings in either.

Thanks for your attention.

>>> import Tkinter, subprocess, _tkinter
>>> Tkinter.Tcl().eval('info patchlevel')
'8.5.11'
>>> print(subprocess.check_output(["otool", "-L", _tkinter.__file__]))
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so:
	/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl (compatibility version 8.5.0, current version 8.5.11)
	/Library/Frameworks/Tk.framework/Versions/8.5/Tk (compatibility version 8.5.0, current version 8.5.11)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
msg178268 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2012-12-27 03:22
Thanks for the additional information.  I am now able to reproduce the behavior you observe when using ActiveTcl 8.5.11.1 and also when using the Apple-supplied 8.5.9 in OS X 10.8; presumably, it is also an issue with earlier versions of Cocoa Tk 8.5.  The good news is that the behavior is no longer observable with ActiveTcl 8.5.12.x and 8.5.13.  I haven't tried to track down what Tk change(s) are responsible.  If you do upgrade your version of Tcl/Tk, avoid 8.5.12.x as there were some serious regressions with it. One of those regressions (Issue15853) remains in 8.5.13 and has been worked around by a change in IDLE.  Until that change is released in Python 3.3.1, 3.2.4, and 2.7.4, you can install a patch for it in 2.7.3.  See http://www.python.org/download/mac/tcltk/ for more details.
msg180639 - (view) Author: Irwin Jungreis (jungreis) Date: 2013-01-26 03:54
I have reopened this issue because there are still cases where it does not work. I installed 8.5.13 and the IDLE patch as suggested. That fixed the particular case that I had used to demonstrate the problem (a file containing just two characters M1). However, the problem still occurs in other cases. To reproduce it, in IDLE pick File | New Window. In the new window type the characters '>>>from' (no spaces, and without the quotes). Now, before clicking anywhere else, move the cursor to the left half of the 'r'. Click once, and the insertion point incorrectly goes to the right of the 'r'. Click a second time without moving the cursor and the insertion point goes to the left side of the 'r'. Unlike the previously reported case, repeated clicking does not cause it to alternate -- only the first click is wrong. I have attached a second video (IMG_1219.MOV) that demonstrates this.
msg180647 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2013-01-26 09:10
Using Cocoa Tk 8.5.13 and IDLE from either 2.7.3 and 3.3.0 on OS X 10.8.2, I can reproduce the behavior you report.  However, I do not see the behavior when using Python 2.7.3 linked with the older Carbon Tk 8.4. I tried without success to reproduce the behavior using a stripped down version of one of the Tk Text widget demos in Wish 8.5.  To me, the most likely cause is either an issue within Tk itself or a Tk 8.5 difference not handled by Tkinter and/or IDLE.  In any case, it seems like a rather minor annoyance compared with most IDLE or Tkinter issues.  If someone wants to investigate further, please feel free to do so.
msg180713 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2013-01-26 21:07
OK, I *did* spend a little more time on this and am now able to reproduce the behavior solely running the following Tcl code with tclsh: 

package require Tk
set w .text
catch {destroy $w}
toplevel $w
text $w.text -setgrid 1 -height 30 -font "Courier 20"
pack $w.text -expand yes -fill both
$w.text tag configure color1 -foreground red
$w.text insert 0.0 ">>>"
$w.text insert end "from" color1
$w.text mark set insert 0.0

Using Cocoa Tk 8.5.13, clicking on the "r" causes the insertion point to move to after the "r" and a second click moves the insertion point to before the "r".  Using the Apple-supplied Carbon Tk 8.4, the insertion point stays after the "r" on the second click.  I suspect the color tag has something to do with it.  I suggest if you want to pursue the issue, you should ask on one of the Tcl mailing lists, like the Mac-specific one (archived here http://dir.gmane.org/gmane.comp.lang.tcl.mac) or open an issue on the Tk tracker:
http://sourceforge.net/tracker/?group_id=12997&atid=112997
History
Date User Action Args
2022-04-11 14:57:39adminsetgithub: 60974
2013-01-26 21:07:48ned.deilysetstatus: open -> closed
resolution: not a bug
messages: + msg180713

stage: resolved
2013-01-26 09:10:22ned.deilysetpriority: normal -> low
messages: + msg180647

assignee: ned.deily ->
resolution: out of date -> (no value)
stage: resolved -> (no value)
2013-01-26 03:54:59jungreissetstatus: closed -> open
files: + IMG_1219.MOV
messages: + msg180639
2012-12-27 03:22:29ned.deilysetstatus: open -> closed
resolution: out of date
messages: + msg178268

stage: resolved
2012-12-25 16:11:22jungreissetfiles: + IMG_1194.MOV

messages: + msg178143
2012-12-25 08:03:50ned.deilysetassignee: ronaldoussoren -> ned.deily

messages: + msg178113
nosy: + ned.deily
2012-12-24 18:32:04jungreiscreate