MacOS Sierra 10.12.6, Python 3.6.1, tk 8.5.15 or .18.  Consider this code with arbitrary compound statements and therefore indented lines.

for i in range(10):
    if i%2:
        print(f(i))

Irv Kalb on idle-dev thread 'Bug in cursor placement in IDLE editor' windows reports the following obnoxious behavior: click just to left or on left side of 'p' and cursor appears on left margin.  Keep clicking and cursor moves right one space at a time until arriving next to 'p', where it should immediately go, and does on Windows, and, I presume, elsewhere.  (When the cursor first arrives at 'p', there is also the double-click selection highlight.)

At my suggestion, he also tested with code inserted directly in a tk Test window with this:

import tkinter as tk
root = tk.Tk()
text = tk.Text(root)
sample = '''
<replace this with sample that allows reported error>
'''
text.insert('1.0', sample)
text.pack()
root.mainloop()

and encountered the same bug.  (Hence, this is not an IDLE issue.)The only difference is that clicking beside keyword 'if' does not show bug in IDLE but does in Text.  He also uploaded an unlisted video to YouTube.
https://www.youtube.com/watch?v=Us8px0BY5rg

Irv's current workaround is to click a letter or two to the right and use <-- key.

I realize that this is likely not a tkinter issue either, but I wanted to record it and get you two's thoughts.  Is this more likely to be a problem with a particular installation, or with at least one macOS release and even 8.5.18.

If the latter, can Irv install Python compiled elsewhere to work with 8.6?  Ned, do you have a recommendation?

Kevin Walzer reported that he does not see the issue with Python built to run with 8.6 and using 8.6.7.  He noted that 8.5.18 does not get bug fixes.  I presume that this applies to 8.5 in general.  Will 3.7.0 be compiled for 8.6?

Thanks for the very helpful video, Irv.  It is definitely not a Python issue as I am able to reproduce the positioning problem using the current ActiveState Community Edition 8.6.6 and 8.5.18 macOS Wish shell text widget demos (as long as I use spaces at the beginning of a line and not tabs).  However, the current MacPorts Tk which has been updated to 8.6.7 does not seem to have this problem, so, if it was fixed in Tk, it was fixed fairly recently.  The python.org 3.7 for macOS will use 8.6 by default prior to feature code off.

Hi Ned,

Thanks for your message.  But I want to make sure I understand what you are saying here.  

I am using absolutely vanilla Python 3.6 from python.org <http://python.org/>, but have upgraded to version 8.5.18  if ActiveState tk.  I was told that this version of Python would not work correctly with the current (8.6) version of tk.  So, I have not installed that.

Am I correct in understanding that this but is not fixable when using Python 3.6?  (That's OK, I just want to make sure.)

It sounds like when Python 3.7 comes out, if I still see the bug, I could upgrade to ActiveState 8.6.7, and that combination should fix the problem.  Is that correct?

Thanks again,

Irv

> On Nov 10, 2017, at 7:00 AM, Ned Deily <report@bugs.python.org> wrote:
> 
> 
> Ned Deily <nad@python.org> added the comment:
> 
> Thanks for the very helpful video, Irv.  It is definitely not a Python issue as I am able to reproduce the positioning problem using the current ActiveState Community Edition 8.6.6 and 8.5.18 macOS Wish shell text widget demos (as long as I use spaces at the beginning of a line and not tabs).  However, the current MacPorts Tk which has been updated to 8.6.7 does not seem to have this problem, so, if it was fixed in Tk, it was fixed fairly recently.  The python.org 3.7 for macOS will use 8.6 by default prior to feature code off.
> 
> ----------
> resolution:  -> third party
> stage:  -> resolved
> status: open -> closed
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue31974>
> _______________________________________
>

3.7.0a2 is out now.  There will be an .0a3, .0a4, then .0b1 in January.  Ned is saying that at least the last of these will be compiled to work with 8.6.  Once that occurs, I would switch as most of the remaining changes before the .0 release will be fixes to new features, which you can not use.  With respect to existing features, 3.7 should be as good as 3.6 as 3.7 has all of the bugfixes in 3.6 plus some that will only appear in the future 3.6.4 release.

Irv, when you reply by email, please delete the quoted previous message (except perhaps for a phrase being specifically addressed).

Update: for Python 3.6.5 and 3.7.0, there are new python.org 10.9+ installer variants that come with a built-in Tcl/Tk 8.6.8.  They are currently both available in testing pre-releases (3.6.5rc1 and 3.7.0b2):

https://www.python.org/download/pre-releases/