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: Idle Code Context menu entrie(s)
Type: behavior Stage: resolved
Components: IDLE Versions: Python 3.8, Python 3.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: terry.reedy Nosy List: cheryl.sabella, miss-islington, taleinat, terry.reedy
Priority: normal Keywords: patch

Created on 2014-10-23 00:16 by terry.reedy, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 11214 merged cheryl.sabella, 2018-12-18 18:59
PR 11286 merged miss-islington, 2018-12-24 14:37
Messages (11)
msg229845 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2014-10-23 00:16
#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.
msg317609 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-05-24 20:02
[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.]
msg317636 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-05-24 22:54
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.
msg317648 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-05-25 00:39
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'.
msg317650 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-05-25 00:43
Changing title since 'separation' has already been done.  Adding a user configuration option is a separate issue.
msg332281 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-12-21 06:31
This is a dependency of #33610.
msg332327 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-12-22 06:47
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.
msg332457 - (view) Author: miss-islington (miss-islington) Date: 2018-12-24 14:37
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
msg332458 - (view) Author: miss-islington (miss-islington) Date: 2018-12-24 14:45
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
msg332663 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2018-12-28 14:53
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.
msg332672 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-12-28 18:22
I understand.  Until tcl/tk can be patched to work with both Mohave and past macOS versions, it is a nasty situation.
History
Date User Action Args
2022-04-11 14:58:09adminsetgithub: 66892
2018-12-28 18:22:31terry.reedysetmessages: + msg332672
2018-12-28 14:53:26taleinatsetmessages: + msg332663
2018-12-24 14:45:14miss-islingtonsetmessages: + msg332458
2018-12-24 14:37:43miss-islingtonsetpull_requests: + pull_request10531
2018-12-24 14:37:30miss-islingtonsetnosy: + miss-islington
messages: + msg332457
2018-12-22 06:47:59terry.reedysetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2018-12-22 06:47:40terry.reedysetnosy: + taleinat
messages: + msg332327
2018-12-21 06:31:43terry.reedysetmessages: + msg332281
versions: - Python 3.6
2018-12-18 18:59:16cheryl.sabellasetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request10451
2018-05-25 00:43:14terry.reedysetmessages: + msg317650
title: Idle Code Context: separate changing current and future editors -> Idle Code Context menu entrie(s)
2018-05-25 00:39:10terry.reedysetmessages: + msg317648
2018-05-24 22:54:32terry.reedysetmessages: + msg317636
2018-05-24 20:02:35terry.reedysetnosy: + cheryl.sabella

messages: + msg317609
versions: + Python 3.8
2018-05-23 05:20:38terry.reedylinkissue33610 dependencies
2017-09-16 19:37:10terry.reedysetversions: + Python 3.6, Python 3.7, - Python 2.7, Python 3.4, Python 3.5
2014-10-23 00:16:55terry.reedycreate