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.

Author terry.reedy
Recipients terry.reedy, wohlganger
Date 2017-08-29.02:57:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1503975446.97.0.770920649131.issue22707@psf.upfronthosting.co.za>
In-reply-to
Content
To expand on the initial statement, changes can take effect a) when IDLE start (the initial window option), b) when a new editor window is created (the initial size option), c) immediately for all editors (indent size and most others), and d) immediately for the active editor (code context toggle).  They should take effect as soon as sensible.

Allowing more individual customization of editors (font, theme, keys, etc) is out of scope for this issue.  I will just note that the values that apply to all editors should have been module or class attributes rather than instance attributes.  This would make updating the attributes easier and faster and would allow instance attributes to be used for instance customization.

The prime violators of 'when' are most of the non-key options that occur in 4 of the built-in extensions.  These are mostly class attributes read just once when the module is imported and the class created, which happens when the first EditorWindow is created.  One exception is Paragraph, where the attribute is an instance attribute, but really should be a Paragraph class or even module attribute.  (I expect the class to be eliminated some day.)  The other is the buggy CodeContext().visible.

What is needed is a mechanism to reload the class attributes after they are changed.  I believe the easiest way would be to wrap the current idleConf load statements in a 'reload' classmethod that is called immediately after the class definition, but which can also be called by configdialog when applying changes.  The class attributes should not be turned into instance attributes that have to be updated in each instance.

I don't remember if I ever checked when changes to user-configurable extension keys takes effect.  It does not matter now.  As part of #27099, converting built-in extensions to features, all key shortcuts will be handled together, so those for former extensions will take effect immediately along with the others.

Most of configdialog been reviewed and tested.  The main exceptions are the button functions, in particular the one for Apply, and the two deactivate and activate methods for themes and keys.  The former extension options will become general options (as will indent spaces).  The update of indent spaces and autosave, which are active when the dialog is closed (I am not currently sure how), might be used as a guide for the new general options.

Testing that changes for general options take effect right away, as intended, is part of this issue, and perhaps the hardest part.
History
Date User Action Args
2017-08-29 02:57:27terry.reedysetrecipients: + terry.reedy, wohlganger
2017-08-29 02:57:26terry.reedysetmessageid: <1503975446.97.0.770920649131.issue22707@psf.upfronthosting.co.za>
2017-08-29 02:57:26terry.reedylinkissue22707 messages
2017-08-29 02:57:25terry.reedycreate