Repository navigation
Idle: changed options should take effect immediately #66896
Description
| BPO | 22707 |
|---|---|
| Nosy | @terryjreedy, @wohlganger |
| Dependencies |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/terryjreedy'
closed_at = None
created_at = <Date 2014-10-23.00:18:13.952>
labels = ['expert-IDLE', 'type-bug', '3.8']
title = 'Idle: changed options should take effect immediately'
updated_at = <Date 2019-02-21.01:08:46.936>
user = 'https://github.com/terryjreedy'bugs.python.org fields:
activity = <Date 2019-02-21.01:08:46.936>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2014-10-23.00:18:13.952>
creator = 'terry.reedy'
dependencies = ['27099']
files = []
hgrepos = []
issue_num = 22707
keywords = []
message_count = 5.0
messages = ['229849', '229913', '300971', '300973', '336169']
nosy_count = 2.0
nosy_names = ['terry.reedy', 'wohlganger']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue22707'
versions = ['Python 3.8']Metadata
Metadata
Assignees
Projects
- Status
Activity
terryjreedy commentedon Oct 23, 2014
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 bpo-22705 for documenting extension options.
terryjreedy commentedon Oct 24, 2014
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 (bpo-22705).
terryjreedy commentedon Aug 29, 2017
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 bpo-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.
terryjreedy commentedon Aug 29, 2017
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.
terryjreedy commentedon Feb 21, 2019
Turning extensions into features bpo-27099 fixed many (all?) unnecessary delays but a few things should be checked, and the help texts reviewed.