Something has been wrong with the underlying Tkinter for several years. A mouse click to select text will mistarget by several lines.

I've held-off reporting this because I couldn't narrow it down to a reproduceable case.  That said, I've seen it on fresh installs of Python on multiple machines with different users.

But now, we have it on video.  It happened to Guido during a keynote.  See https://www.youtube.com/watch?v=0Ef9GudbxXY at about 7:00 to 7:30.

Watched that video clip - yikes, that is bad.

I tried playing around to reproduce it, but haven't had any success yet, though did find another weird thing. If you have a bunch of short lines without any blanks, sometimes when you click well to the right of all of them, the cursor will end up at the beginning of one of the lines, rather than at the end of them. This wasn't consistent but did happen maybe 1/10th of the time.

Guido was running on a Mac. Were the other examples where you saw this missing by several lines also all on Mac?  (Not to say that means it's a Mac only bug, but...)

A wild guess: could it be dependent on the screen resolution, in particular if a Mac Retina display is in use? It also could depend on the version of Tk; from the screenshot it is clear that Guido was not using a python.org version of 3.4 so the out-of-date Apple-supplied Tk *might* be in use.

Guido, we are looking at the PyCon 2014 keynote video where the text cursor was misplaced relative to the mouseclick, trying to guess the reason. Do you still have the Mac laptop you used? If so, have you upgraded its python?

The hideous moment is at 7:10. Guido clicked after '.split' to position the blinking insert cursor there, to add 'lines' to the method name. There was no reason to select anything. The cursor appeared instead on the blank line 4 lines above. Guido was able to move the text cursor with arrow keys, as normal, to the desired position.

Serhiy or Kevin, have either of you seen or heard of this problem?

Earlier in the video, there are Display boxes offering resolution choices of 800x600, 1024x768, and 1280x1024. I presume that this indicates 'not Retina'.

I suspect the OS or tk they jointly control the text cursor. Minimal code for experiments is:

import tkinter as tk
root = tk.Tk()
text = tk.Text()
text.pack()
root.mainloop()

Running the above on Win7, I tried Mark's experiment. Clicking near the end of a line consistently put the cursor at the end of the line.  Clicking near the right edge of the box, at least 50 columns away, consistently put the cursor at the beginning of *some* line, but not necessarily the one 'clicked' on.

I looked at idlelib.EditorWindow for anything that might possibly affect tk processing of left button clicks. I only found 2 items.

        if macosxSupport.isAquaTk():
            text.bind("<Control-Button-1>",self.right_menu_event)
If the problem were Mac-specific, this might warrant a look.

        self.text.event_add("<<set-line-and-column>>",
                            "<KeyRelease>", "<ButtonRelease>")
The cursor is positioned on buttom press, before release.

[Ned]
> the out-of-date Apple-supplied Tk *might* be in use.

It also happens to me and my students periodically.  Our Tk is up-to-date.

I don't have that laptop any more. It's likely that the screen resolution change caused Tcl/Tk to be confused. That's probably a Tcl/Tk bug.

I suspect that this is entirely a tkinter problem, not an IDLE problem.  For the editor, ButtonRelease is bound to set_line_and_column which updates the status bar.  The function return None so tk can handle the click to move the cursor.

Perhaps this should be closed as 3rd party.  I doubt _tkinter messes with clicks.

Is this still reproducible? 

A question to those that can reproduce this: does this happen with the built-in screen (assuming a laptop or iMac) or an external interface? If the latter, is that a retina display? And does this happen more when moving IDLE from a retina display to a non-retina display?

https://stackoverflow.com/questions/69038343/mouse-pointer-misaligned-when-using-python-in-idle-on-mac reports same issue with 3.9.5.  I have requested details to be posted here.