You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
IDLE - Add an extension configuration dialog #47318
Attaching a patch for a straightforward extension config dialog, largely
based on configDialog.py.
This uses the multiple-tab-rows feature of the TabbedPageSet widget from
the tabbedPages module, as well as the included VerticalScrolledFrame
widget. Other than that there's nothing really new here.
This patch also removes the "paragraph width" option from the "General"
tab in the normal IDLE config, since that configures a parameter of the
FormatParagraph extension, which can now be done in the extension config
dialog.
I expect I will look at this eventually. However, my priorities are bugs, tests, and enhancements that benefit me. From the description, this moves one configuration option that I do not use to a new dialog. So I do not see any immediate improvement for me. Is the idea to have a framework in place for new extensions that have configuration options?
I am not really clear on why some features, like reformat, are considered 'extensions' rather than just normal features, and why its configuration should be segregated.
The comment "A pure Tkinter scrollable frame that actually works!" suggests that there is somewhere a scrollable frame that does not work. The docs? The tkinter package? In any case, this seems like something that perhaps should go in the tkinter package.
As the title suggests, this patch adds a second configuration dialog, used to configure extensions.
This is useful because many extensions have parameters, but setting them can only be done by editing a file. Also, the documentation for such parameters is hard to find (when it exists). Finally, it allows us (the IDLE devs) to add more default extensions, allowing users to easily configure them or disable them, all without cluttering the regular config dialog.
Regarding the patch, please note that it is from 5.5 years ago. Back then there was no scrollable frame that worked properly, so I implemented one which worked well enough for the config dialogs. I didn't test it thoroughly enough in other scenarios to suggest adding it to Tkinter.
I think that since then a proper scrollable frame was added to Tk, so that part of the patch is probably no longer necessary.
(Because of PEP-434, this could be added to all current versions if and when it is added. Marking for 3.5 is enough for now.)
I am not yet very familiar with either extensions or configuration.
many extensions have parameters, but setting them can only be done by editing a file
If this is true of existing extensions (and I don't even know which features are 'extensions), then this patch would be useful now. Otherwise, it could wait until new extensions are included.
As I understand the patch so far, it creates a generic tab from a section of a configuration file. Would 3rd party extensions add such a section? Or do we really need a mechanism for extension files to define a tab for the extension. (This would also enable custom placements of fields.)
I personally have no need to disable extensions, but if there were another 10 or 20, I can imagine a class instructor would like a way to easily simplify the interface, or to make a custom extension easier to work with.
the documentation for such parameters is hard to find (when it exists)
I recently disabled the useless help button on the configuration dialog. I think what is needed is a tab-specific help text. That would work especially well for extension-specific tabs, but we would need a mechanism to get help text from an extension file.
You'd be surprised how many of IDLE's features are implemented as extensions. These are simply included in idlelib, enabled by default and configured with reasonable values.
Take a look at Lib/idlelib/config-extensions.def, and you'll see all of the bundled extensions' configuration values. (Every extension must have a section in config-extensions.def or a user's config-extensions.cfg to be enabled.)
So, for example, auto-completion is an extension. Besides disabling it completely, a user can also change the delay before the completion list appears automatically by setting 'popupwait', and customize the key bindings for the 'autocomplete' and 'force-open-completions' events.
The 'ParenMatch' and 'CodeContext' extensions also each have several configurable settings. And most extensions have at least one event to which keyboard shortcuts can be bound.
If after all of the above you look again at the 'FormatParagraph' extension, you'll see that it's breaking the convention. The maximum line width is configurable, but isn't found in config-extensions.def! Instead of using the normal extension configuration mechanism, FormatParagraph reads the 'maxformatwidth' config value from IDLE's main configuration on every call to format_paragraph_event().
Why was this done? To allow users to configure this setting using the GUI instead of editing a config file! If a config dialog for extensions had existed, this hack wouldn't have been necessary.
So what does my patch achieve?
It makes many more of IDLE's settings easy to discover, set and fiddle with. Some of these are actually useful, e.g. AutoComplete's 'popupwait' setting.
Makes it reasonable to tell a user "just disable auto-completions from the extension config dialog". (Without this patch: "find your .idlerc folder; open the config-extensions.cfg file or create one if it doesn't exist; find the [AutoComplete] section; make sure enable=0 is written directly under it".)
Removes the inconsistent hack in FormatParagraph.format_paragraph_event().
Makes it more reasonable to bundle more extensions with IDLE (such as my Squeezer extension; see bpo-1529353).
Thank you! This is a bit of the 'Idle Developer's Guide' that I wish existed. It turns out that the exceptional FormatParagraph.py is the one extension file I am really familiar with, because I worked with a GSOC student to write tests and fix/improve it. I agree that this would be useful now.
I tried applying the patch and Hg say this:
abort: unable to strip away 1 of 1 dirs from Bindings.py
Since the patch just adds a line, I do not understand the message.
Do you have any ideas?
Please do; the devguide says which format is preferred. While you are at it, please
write it against 3.3, leaving a 2.7 backport for last;
just add the new stuff, leaving format-paragraph changes for a separate patch;
consider the format points I raised with bpo-20569 (if you disagree, let's discuss)
a. 'import tkinter as tk'
b. a new test file
c. shorter, lowercase title, such as 'configex.py', or...
d. is a new file really needed? or add to what is now called configDialog.py?
I am ready to do this. While it is too late for 3.3.4 and 3.4.0 (rc1) due out today, I would like to have this in and tested in use for subsequent releases after that (2.7.7, the final 3.3.5, 3.4.1, and of course, 3.5.0).
While reviewing bpo-20569 I realized that having an easy way to enable/disable extensions would lower the bar for adding new ones. The fact that some people would not want something present would not prevent having it available to others. (This point is true even if a clipboard history or snippets list could not be added as an extension.)
A current 'Future of Python' thread on idle-sig reminded me that multiple people would like 1 or more of the tested idlex extensions added. This dialog would make additions easier by making their use easier. That thread also suggested that Idle needs more 'excitement', which means some new features. Tests and bug fixes, though important, tend to be boring to most people. So I have adjusted my priorities a bit.
Saimadhav, since you did not mention a problem with the appearance of the True/False button or the action buttons, which were issues before, I presume they are okay.
S1. For Shell, which does not have Format, alt-O opens Options. The hot key for Format should be changed to 't' so its addition does not diable O_ptions. I will do this in a separate patch.
S2. For my first patch, I see all 5 files. For -2, I only see entry for Binding.py. Odd since the only difference is the better line endings (and date stamps). When I uploaded this, it took about 10 minutes for 'review' to be added. I don't know if that is normal as I never paid attention before. Please post query.
I see the problem with the text entry boxes. I will look for a fix.
I have always been bothered by 'Options' -> 'Configure' -> 'Preferences'. Hotkeys should be 'I' and 'E'. I think 'Idle' and 'Extensions' might be enough, without 'Configure'.
I agree and will delete ... both places.
I have not actually looked at the file written, as Ned's review and my edits focused on glitches in the appearance of the dialog itself. I agree that if nothing is changed, nothing need be written. If anything is changed, the entire file has to be written. But I agree that for default extensions in config-extensions.def, only writing the delta, as done with config-main.cfg versus config-main.def, would be good. This requires noticing which extensions *are* in config-extensions.def. Sections for extensions only in the user file must be written back in full. I will look at how saving deltas works for config-main.cfg, but I may want to make this a followup patch.
I reused the names from the existing dialogs (config and others), which match the button label and handler name. These are the capitalized method names I find least bad. I would also be happy to change them just here or everywhere. I don't want this to hold up this patch if there is disagreement.
Commenting out is temporary, purely for development.
S1. The top menu bar hot keys are set in EditorWindow.menu_specs. 'Options' *can* be opened, at least on Windows, with alt O O <enter> (and Format with alt O <enter>). Conflicts are definitely Not Good. Any strong opinions on marking 'm' veras 't'?
Referring to previous item numbers, this new patch, relative to -2,
adds padx to gridding of entry widgets. (Note, editor text area runs against scroll bar in same way as these did, but without breaks, it looks fine.) Padding border looks better to me.
changes shortcuts to _I and _E.
deletes '...'.
---
With respect to
Save_all_changed_configs is supposed to only save if 'changes', and set_user_value is supposed to removed 'changes' same as default. I want to review these functions after uploading the changes above, along with addition of title and use of _htest in .__init__.
Reuse of create_action_buttons requires that action handlers have matching names in both dialogs. Since this does not affect dialog behavior, I want to defer this.
I intend to uncomment before pushing, but this does not affect dialog use.
The reason for the apparent writing of unchanged values is that '0' != 'False' and '1' !- 'True'. With all booleans writen as 'False' or 'True', non-enable boolean items can be recognized and non-changes not seen as changes. I will next revise the patch and retest.
cfg-ext-34-4.diff: In this patch, default values are classified as bool, int, on other. An invalid user bool or int value is replaced by the corresponding default (which had to be a valid bool or int for the type to be set) and the invalid value is either removed or replaced by a valid value. To this extent, this dialog will repair a corrupted config-extensions.cfg. Int values get an entry box with validation.
The validation allows blank strings for int entries (which, of course are also allowed for 'other'. All non-key options for default extensions must have a value. So in set_user_value, if there is a default, a blank value is treated the same as if it were the default, and the user config line removed if there is one. So blanking an entry is a way to set is to the default value.
I think this is about ready to commit. It should first be tested with an added section in the user config for an added extension. I also think set_user_value should be able to use the already fetched and saved default value.
S2: For patch 3, Rietveld shows all 5 files. It momentarily showed 5 for patch 2, then reverted to just 1.
This version only allows configuration of default configuration. Added sections (for added extensions) are ignored. That will be a future enhancement.
Patch 5 makes changes in load_extensions and set_user_value so that var strings are compared to saved default strings. Before doing that, the value is stripped and if blank replaced with the default. The var is set to the adjusted value. After Apply, the user can see what the current config values are and if not default, what was written to the user config file.
Tal, thank you updating and submitting your patch. It fills a real hole in Idle customization. I am already using it to tweek the completion popup delay to find the best value for me.
I opened these followup issues. bpo-22703 fix the behavior of Options / Code Context bpo-22704 rethink 'enable_xyz' system and use consistently bpo-22705 add 'option-help' option for doc and entry checking bpo-22706 write [x] and [x_config...] sections together in user .cfg bpo-22707 makes changes take effect immediately or indicate if not
I will later review this issue to see if I missed anything else.
I am leaving this open until I add a user-oriented news item and edit the Idle doc.
Activity
taleinat commentedon Jun 9, 2008
Attaching a patch for a straightforward extension config dialog, largely
based on configDialog.py.
This uses the multiple-tab-rows feature of the TabbedPageSet widget from
the tabbedPages module, as well as the included VerticalScrolledFrame
widget. Other than that there's nothing really new here.
taleinat commentedon Jun 9, 2008
I forgot to mention:
This patch also removes the "paragraph width" option from the "General"
tab in the normal IDLE config, since that configures a parameter of the
FormatParagraph extension, which can now be done in the extension config
dialog.
taleinat commentedon Feb 4, 2014
Is there any chance this patch could get some love? I've stopped using IDLE a long time ago, but this patch is a great improvement!
terryjreedy commentedon Feb 4, 2014
I expect I will look at this eventually. However, my priorities are bugs, tests, and enhancements that benefit me. From the description, this moves one configuration option that I do not use to a new dialog. So I do not see any immediate improvement for me. Is the idea to have a framework in place for new extensions that have configuration options?
I am not really clear on why some features, like reformat, are considered 'extensions' rather than just normal features, and why its configuration should be segregated.
The comment "A pure Tkinter scrollable frame that actually works!" suggests that there is somewhere a scrollable frame that does not work. The docs? The tkinter package? In any case, this seems like something that perhaps should go in the tkinter package.
taleinat commentedon Feb 4, 2014
As the title suggests, this patch adds a second configuration dialog, used to configure extensions.
This is useful because many extensions have parameters, but setting them can only be done by editing a file. Also, the documentation for such parameters is hard to find (when it exists). Finally, it allows us (the IDLE devs) to add more default extensions, allowing users to easily configure them or disable them, all without cluttering the regular config dialog.
Regarding the patch, please note that it is from 5.5 years ago. Back then there was no scrollable frame that worked properly, so I implemented one which worked well enough for the config dialogs. I didn't test it thoroughly enough in other scenarios to suggest adding it to Tkinter.
I think that since then a proper scrollable frame was added to Tk, so that part of the patch is probably no longer necessary.
terryjreedy commentedon Feb 5, 2014
(Because of PEP-434, this could be added to all current versions if and when it is added. Marking for 3.5 is enough for now.)
I am not yet very familiar with either extensions or configuration.
If this is true of existing extensions (and I don't even know which features are 'extensions), then this patch would be useful now. Otherwise, it could wait until new extensions are included.
As I understand the patch so far, it creates a generic tab from a section of a configuration file. Would 3rd party extensions add such a section? Or do we really need a mechanism for extension files to define a tab for the extension. (This would also enable custom placements of fields.)
I personally have no need to disable extensions, but if there were another 10 or 20, I can imagine a class instructor would like a way to easily simplify the interface, or to make a custom extension easier to work with.
I recently disabled the useless help button on the configuration dialog. I think what is needed is a tab-specific help text. That would work especially well for extension-specific tabs, but we would need a mechanism to get help text from an extension file.
taleinat commentedon Feb 5, 2014
(This is a bit long; there's a TL;DR at the end.)
You'd be surprised how many of IDLE's features are implemented as extensions. These are simply included in idlelib, enabled by default and configured with reasonable values.
Take a look at Lib/idlelib/config-extensions.def, and you'll see all of the bundled extensions' configuration values. (Every extension must have a section in config-extensions.def or a user's config-extensions.cfg to be enabled.)
So, for example, auto-completion is an extension. Besides disabling it completely, a user can also change the delay before the completion list appears automatically by setting 'popupwait', and customize the key bindings for the 'autocomplete' and 'force-open-completions' events.
The 'ParenMatch' and 'CodeContext' extensions also each have several configurable settings. And most extensions have at least one event to which keyboard shortcuts can be bound.
If after all of the above you look again at the 'FormatParagraph' extension, you'll see that it's breaking the convention. The maximum line width is configurable, but isn't found in config-extensions.def! Instead of using the normal extension configuration mechanism, FormatParagraph reads the 'maxformatwidth' config value from IDLE's main configuration on every call to format_paragraph_event().
Why was this done? To allow users to configure this setting using the GUI instead of editing a config file! If a config dialog for extensions had existed, this hack wouldn't have been necessary.
So what does my patch achieve?
terryjreedy commentedon Feb 5, 2014
Thank you! This is a bit of the 'Idle Developer's Guide' that I wish existed. It turns out that the exceptional FormatParagraph.py is the one extension file I am really familiar with, because I worked with a GSOC student to write tests and fix/improve it. I agree that this would be useful now.
terryjreedy commentedon Feb 8, 2014
I tried applying the patch and Hg say this:
abort: unable to strip away 1 of 1 dirs from Bindings.py
Since the patch just adds a line, I do not understand the message.
Do you have any ideas?
taleinat commentedon Feb 9, 2014
It's an old patch and it may not be in a properly recognized format.
I'll create a new patch soon.
terryjreedy commentedon Feb 9, 2014
Please do; the devguide says which format is preferred. While you are at it, please
a. 'import tkinter as tk'
b. a new test file
c. shorter, lowercase title, such as 'configex.py', or...
d. is a new file really needed? or add to what is now called configDialog.py?
I am ready to do this. While it is too late for 3.3.4 and 3.4.0 (rc1) due out today, I would like to have this in and tested in use for subsequent releases after that (2.7.7, the final 3.3.5, 3.4.1, and of course, 3.5.0).
While reviewing bpo-20569 I realized that having an easy way to enable/disable extensions would lower the bar for adding new ones. The fact that some people would not want something present would not prevent having it available to others. (This point is true even if a clipboard history or snippets list could not be added as an extension.)
A current 'Future of Python' thread on idle-sig reminded me that multiple people would like 1 or more of the tested idlex extensions added. This dialog would make additions easier by making their use easier. That thread also suggested that Idle needs more 'excitement', which means some new features. Tests and bug fixes, though important, tend to be boring to most people. So I have adjusted my priorities a bit.
15 remaining items
terryjreedy commentedon Oct 14, 2014
Saimadhav, since you did not mention a problem with the appearance of the True/False button or the action buttons, which were issues before, I presume they are okay.
S1. For Shell, which does not have Format, alt-O opens Options. The hot key for Format should be changed to 't' so its addition does not diable O_ptions. I will do this in a separate patch.
S2. For my first patch, I see all 5 files. For -2, I only see entry for Binding.py. Odd since the only difference is the better line endings (and date stamps). When I uploaded this, it took about 10 minutes for 'review' to be added. I don't know if that is normal as I never paid attention before. Please post query.
I see the problem with the text entry boxes. I will look for a fix.
I have always been bothered by 'Options' -> 'Configure' -> 'Preferences'. Hotkeys should be 'I' and 'E'. I think 'Idle' and 'Extensions' might be enough, without 'Configure'.
I agree and will delete ... both places.
I have not actually looked at the file written, as Ned's review and my edits focused on glitches in the appearance of the dialog itself. I agree that if nothing is changed, nothing need be written. If anything is changed, the entire file has to be written. But I agree that for default extensions in config-extensions.def, only writing the delta, as done with config-main.cfg versus config-main.def, would be good. This requires noticing which extensions *are* in config-extensions.def. Sections for extensions only in the user file must be written back in full. I will look at how saving deltas works for config-main.cfg, but I may want to make this a followup patch.
I reused the names from the existing dialogs (config and others), which match the button label and handler name. These are the capitalized method names I find least bad. I would also be happy to change them just here or everywhere. I don't want this to hold up this patch if there is disagreement.
Commenting out is temporary, purely for development.
terryjreedy commentedon Oct 14, 2014
S1. The top menu bar hot keys are set in EditorWindow.menu_specs. 'Options' *can* be opened, at least on Windows, with alt O O <enter> (and Format with alt O <enter>). Conflicts are definitely Not Good. Any strong opinions on marking 'm' veras 't'?
terryjreedy commentedon Oct 14, 2014
Referring to previous item numbers, this new patch, relative to -2,
adds padx to gridding of entry widgets. (Note, editor text area runs against scroll bar in same way as these did, but without breaks, it looks fine.) Padding border looks better to me.
changes shortcuts to _I and _E.
deletes '...'.
---
With respect to
Save_all_changed_configs is supposed to only save if 'changes', and set_user_value is supposed to removed 'changes' same as default. I want to review these functions after uploading the changes above, along with addition of title and use of _htest in .__init__.
Reuse of create_action_buttons requires that action handlers have matching names in both dialogs. Since this does not affect dialog behavior, I want to defer this.
I intend to uncomment before pushing, but this does not affect dialog use.
python-dev commentedon Oct 14, 2014
New changeset 7ba47bbfe38d by Terry Jan Reedy in branch '2.7':
Issue bpo-3068: Change 0/1 to False/True so that extension configure dialog can
https://hg.python.org/cpython/rev/7ba47bbfe38d
New changeset 94f8d65371b7 by Terry Jan Reedy in branch '3.4':
Issue bpo-3068: Change 0/1 to False/True so that extension configure dialog can
https://hg.python.org/cpython/rev/94f8d65371b7
New changeset 111d535b52e8 by Terry Jan Reedy in branch 'default':
Merge with 3.4 bpo-3068
https://hg.python.org/cpython/rev/111d535b52e8
terryjreedy commentedon Oct 14, 2014
The reason for the apparent writing of unchanged values is that '0' != 'False' and '1' !- 'True'. With all booleans writen as 'False' or 'True', non-enable boolean items can be recognized and non-changes not seen as changes. I will next revise the patch and retest.
terryjreedy commentedon Oct 15, 2014
cfg-ext-34-4.diff: In this patch, default values are classified as bool, int, on other. An invalid user bool or int value is replaced by the corresponding default (which had to be a valid bool or int for the type to be set) and the invalid value is either removed or replaced by a valid value. To this extent, this dialog will repair a corrupted config-extensions.cfg. Int values get an entry box with validation.
The validation allows blank strings for int entries (which, of course are also allowed for 'other'. All non-key options for default extensions must have a value. So in set_user_value, if there is a default, a blank value is treated the same as if it were the default, and the user config line removed if there is one. So blanking an entry is a way to set is to the default value.
I think this is about ready to commit. It should first be tested with an added section in the user config for an added extension. I also think set_user_value should be able to use the already fetched and saved default value.
S2: For patch 3, Rietveld shows all 5 files. It momentarily showed 5 for patch 2, then reverted to just 1.
terryjreedy commentedon Oct 15, 2014
This version only allows configuration of default configuration. Added sections (for added extensions) are ignored. That will be a future enhancement.
Patch 5 makes changes in load_extensions and set_user_value so that var strings are compared to saved default strings. Before doing that, the value is stripped and if blank replaced with the default. The var is set to the adjusted value. After Apply, the user can see what the current config values are and if not default, what was written to the user config file.
terryjreedy commentedon Oct 15, 2014
Patch 5 was missing the last change. Ignore it unless here is a problem with 5a
python-dev commentedon Oct 23, 2014
New changeset 1d708436831a by Terry Jan Reedy in branch '2.7':
Issue bpo-3068: Add Idle extension configuration dialog to Options menu.
https://hg.python.org/cpython/rev/1d708436831a
New changeset d2a045855c4e by Terry Jan Reedy in branch '3.4':
Issue bpo-3068: Add Idle extension configuration dialog to Options menu.
https://hg.python.org/cpython/rev/d2a045855c4e
New changeset d70b70a661c6 by Terry Jan Reedy in branch 'default':
Merge with 3.4 bpo-3068
https://hg.python.org/cpython/rev/d70b70a661c6
terryjreedy commentedon Oct 23, 2014
Tal, thank you updating and submitting your patch. It fills a real hole in Idle customization. I am already using it to tweek the completion popup delay to find the best value for me.
I opened these followup issues.
bpo-22703 fix the behavior of Options / Code Context
bpo-22704 rethink 'enable_xyz' system and use consistently
bpo-22705 add 'option-help' option for doc and entry checking
bpo-22706 write [x] and [x_config...] sections together in user .cfg
bpo-22707 makes changes take effect immediately or indicate if not
I will later review this issue to see if I missed anything else.
I am leaving this open until I add a user-oriented news item and edit the Idle doc.
terryjreedy commentedon Oct 25, 2014
bpo-22726 Add help to both dialogs
python-dev commentedon Dec 4, 2014
New changeset 395673aac686 by Terry Jan Reedy in branch '2.7':
Issue bpo-3068: Document the new Configure Extensions dialog and menu entry.
https://hg.python.org/cpython/rev/395673aac686
New changeset b099cc290ae9 by Terry Jan Reedy in branch '3.4':
Issue bpo-3068: Document the new Configure Extensions dialog and menu entry.
https://hg.python.org/cpython/rev/b099cc290ae9