Currently, some option changes take effect immediately, and some only when Idle is started again.  To the extent possible, options should take effect immediately, perhaps by not caching values outside of the config dictionary that records changes before they are written out.

Where immediately effect is not possible, there should be an indication. See #22705 for documenting extension options.

For Idle preferences, a Help text could list options that do not take effect immediately.  For extensions, there should be an indication in an extension's option-help (#22705).

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.

I looked at the how the num_spaces and current General options are defined, set, and updated.

editor-on-startup: local name in pyshell.main.

width, height: used in text_options, passed to MultiCallCreator(Text). (Width is EW() attribute, initialized in EW.__init__, but only used immediately in text_options.)

autosave: local name in runscript.ScriptBinding.getfilename, called each time one runs a module.  This a runscript extension option already put on General tab and saved in config-main.

num_spaces: EditorWindow() attribute, set in EW.set_notabs_indentwidth, called in EW.__init__ and ConfigDialog.activate_config_changes for each window.

help_list: local name in EW.reset_help_menu_entries, called in EW.__init__ and CD.a_c_changes, like num_spaces.


For new General options, add EW.reload_general(), which calls class reload methods.  In CD.a_c_w, add at the end, after the loop, 'win_instances.pop().reload_general()'.  This will avoid importing the feature modules into configdialog.

Turning extensions into features #27099 fixed many (all?) unnecessary delays but a few things should be checked, and the help texts reviewed.