homepage

#17535, msg225416, 2014年08月16日 17:18 describes the current double behavior of Options / Code context. It toggles the code-context state of both the current editor and the default for future editors. The two toggles can be in opposite directions. The check mark absent or present somewhat surprisingly indicates the initial state of future windows, not of the current window.
The consensus seemed to be that we should change to having Code Context toggle the current window only, with the checkmark indicating its current state. The default for future windows will be left to the extension configuration, which will be easy to change with the new dialog, #3068.

[In #33610, msg317601, Cheryl Sabella wrote, copying here:]
I've started looking at #22703, more specifically, I've been trying to recreate it. Since the config changes in 3.6/3.7 where the flag was removed from config dialog, the code context needs to be turned on explicitly for each editor. 3.5 has the old behavior.
So, I think the current change would be to add it back to config but with the behavior defined in #22703. 
I hope to have a PR within the next few days.
[ I will respond in a new message after investigating the current situation, versus 3 1/2 years ago.]

Cheryl, you are right. The extension-feature conversion made this issue mostly obsolete. Editors start without code context and the menu only toggles the current window.
If I had thought about it, I would have closed this or added an update last fall. And I should have retested this yesterday. The differences from what I proposed above are more or less intentional. So don't write a patch until we agree on a list of changes.
I re-read #17535, msg225416, 2014年08月16日 17:18, where this started, but not the discussions on the tracker and PR about the conversion details.
---
MENU has no checkmark: I noted on msg225416 that the checkmark never indicated the current state of the current window and that there was hardly any need to keep it and change its meaning, because the current state of the current window is plainly visible. I am currently inclined to leave it off. Instead, I would like to prefix 'Code Context' with 'Toggle'. What do you think? Whatever we do would be a precedent for other local options, such as a line number toggle, both on this menu and a context menu.
Since the effect of 'Code Context' is only local and not global, there should at least be a line separator after the global settings entry. I might even like a dummy entry such as 'Current window:' after the line.
Local options should also be on the right-click context menu. Based on my experience with using breakpoints, I want to try replacing the current line options 'Set Breakpoint' and 'Clear Breakpoint' with 'Toggle Breakpoint'. 'Toggle Code Context' would go with this. 
---
Initial presence of CC in new windows: config-extensions.def has
 [CodeContext]
 numlines= 3
 visible= False
'numlines' is read and used. 'visible' is ignored. To be sure, I added 'visible=True' to config-extensions.cfg and it made no difference.
To enable CC defaulting to on for new editors, we would add a checkbox "[ ] Initially Visible" after the "Context lines [ ]" box on the General tab, much like the "[ ] Bell on Mismatch" above on the same tab. Saving changes would be the same. The added wiring would be a bit different.
This would not be re-enabling anything that properly worked before the conversion. One had to enable the feature, turn on 'visible' and then either never use the toggle or go back through the dialog to turn on 'visible' after the toggle turned it off. Then, once one had CC running, there was the tradeoff between too many blank lines and too few real context lines. I suspect most people left CC disabled even after trying it out.
I don't feel it a rush to add this option until it is plausibly something someone might do. The aim of #33610 is to make this be true. In any case, this might be better as a PR separate from fiddling with the menus.
I intentionally did not say 're-enable' 
As I remember, I did not do this because I could not believe that much of anyone was intentionally setting visible=True, at least for very long. using this option. Having too many blank lines
Open editor, no cc. Toggle, cc. Open another editor, no cc.
Close IDLE. Add the following .idlerc/config-extensions.cff.
[CodeContext]
visible= True
OpenIDLE, open editor, no cc.

An experienced non-CS computer user I asked does not like 'toggle x' or 'switch x', but would like whichever of 'show x' and 'hide x' is appropriate (rather than both). For breakpoints, this would mean one menu entry, either 'set breakpoint' or 'clear breakpoint', rather than both (as currently).
A few Menu entries are labelled 'Show x'. They don't need a 'Hide' menu variant as hiding is done otherwise.
Checkmarks are OK, but she would prefer an empty box or circle as an dialogs, so that clicking more obviously means 'turn on' when in the 'off' state.
It occurs to me now, after at least 20 years of using menus, that the logic of 'blank' is that 'blank' means 'do something', so that 'check' means 'something was done, undo it'. But I think that clicking 'clear breakpoint', for instance, is clearer than clicking 'v breakpoint', where 'v' represents a checkmark'.

Changing title since 'separation' has already been done. Adding a user configuration option is a separate issue.

This is a dependency of #33610.

Both pr-11214 and the pr-11286 (3.7 backport, not listed below) have been merged.
Tal: I am pretty sure the Options menu should continue to work on Macs, but a test to verify would be helpful.

New changeset c1b4b0f6160e1919394586f44b12538505fed300 by Miss Islington (bot) (Cheryl Sabella) in branch 'master':
 bpo-22703: IDLE: Improve Code Context and Zoom Height menu labels (GH-11214)
https://github.com/python/cpython/commit/c1b4b0f6160e1919394586f44b12538505fed300

New changeset 48a206978c890387aa573991cfe992d0c1951048 by Miss Islington (bot) in branch '3.7':
bpo-22703: IDLE: Improve Code Context and Zoom Height menu labels (GH-11214)
https://github.com/python/cpython/commit/48a206978c890387aa573991cfe992d0c1951048

Terry, I'm having trouble getting Tk to work on my Mac since the Mojave update, so I'm not yet able to check this.

I understand. Until tcl/tk can be patched to work with both Mohave and past macOS versions, it is a nasty situation.