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.

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.

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!

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.

(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?

* 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 issue1529353).

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?

It's an old patch and it may not be in a properly recognized format.

I'll create a new patch soon.

Please do; the devguide says which format is preferred. While you are at it, please
1. write it against 3.3, leaving a 2.7 backport for last;
2. just add the new stuff, leaving format-paragraph changes for a separate patch;
3. consider the format points I raised with #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 #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.

I'm glad that adding features to IDLE is being considered! However, I really think that new features should be chosen with extreme care. Adding advanced features aimed mostly at "power" users should be avoided unless really necessary, IMO.

The reason I'm pushing this extension is because it is straight-forward to use and make things using IDLE easier and less frustrating, especially for novice users.

Here's an updated patch. As requested, the patch is against the current 3.3 branch and applies cleanly to default.

I tested with both Python 3.3.4 RC1 and 3.4.0 beta 3, while overriding their idlelib with the one from the repo with these changes.

I also removed from this patch the moving of the line width setting for the FormatParagraph extension from the base config dialog to the extensions config. See separate patch for this in issue20577.

I did a very quick test on OS X.  Comments:

1. In keeping with Apple Human Interface Guidelines, the "Options" menu is different on OS X: the "Configure IDLE" menu item appears as a "Preferences" menu item in the "IDLE" application menu row.  So, as it stands, adding the "Configure Extensions" menu item doesn't work on OS X due to the menu tailoring.  This addition makes it work:

diff --git a/Lib/idlelib/macosxSupport.py b/Lib/idlelib/macosxSupport.py
--- a/Lib/idlelib/macosxSupport.py
+++ b/Lib/idlelib/macosxSupport.py
@@ -141,9 +141,9 @@
     # menu
     del Bindings.menudefs[-1][1][0:2]

-    # Remove the 'Configure' entry from the options menu, it is in the
+    # Remove the 'Configure IDLE' entry from the options menu, it is in the
     # application menu as 'Preferences'
-    del Bindings.menudefs[-2][1][0:2]
+    del Bindings.menudefs[-2][1][0]

     menubar = Menu(root)
     root.configure(menu=menubar)

2. The buttons on the Extensions Configuration aren't wide enough for the default Cocoa Tk 8.5 text on them (Ok, Apply, Cancel) so they overflow to two lines.  In contrast, the similar buttons on the IDLE Preferences window display correctly.

3. On the ParenMatch configuration tab, there is a text box for "style" (with the default value of "expression").  There is no clue to what this means or what values are valid.  Could this be some other widget if there is a known set of value?

4. If the enabled setting for CallTips are changed while edit windows are open, the existing windows are not affected.  New edit windows do observe the new setting.  (I didn't try this with other extensions.)

5. The appearance of the boolean options on the extensions panels vary among the various Tk's supported on OS X and none of the result are totally satisfactory; see the images in the zipfile upload.  I think the main problem is that the widgets are centered in the frame.  For Cocoa Tk, this results in a check box towards the left and the label centered in the remaining space.  For the other two (Carbon 8.4 and X11, it results in a very wide toggle button.


It would probably be a good idea for someone who uses IDLE to do a more thorough review of all of the options on all of the Tk variants we support (e.g. Windows, Linux X11, OS X Cocoa, OS X Carbon, OS X X11).  As this quick look shows, there are almost always differences (subtle and not so subtle) among them.

Ned, many thanks for the review and detailed feedback!

Here are responses to your comments

1. Thanks for the code suggestion regarding the menudefs! That's a good catch. I have an OSX box for such testing.

2. I'll check this out. Could you perhaps explain or point me to resources regarding how to run IDLE with various Tk implementations on OSX?

3. Unfortunately, IDLE's config mechanism doesn't have special support for options with only several valid values, as would have been ideal for ParenMatch's "style" parameter. As it is, these are just considered strings, and no explicit error occurs if an invalid value is specified. Without upgrading the config mechanism itself, the config dialog has no way of supplying the valid values and/or validating user input of such values. This could be useful, but should be considered a separate issue IMO. I would be happy to add relevant support to the dialog once the underlying support is implemented.

4. Regarding having thing updated only on new windows or after restart, AFAIK that is currently the case with many options in the existing config dialog. Ideally the behavior would be consistent for all config options, and even more ideally all config changes would take effect immediately. However, that would require major changes to IDLE. Again, I think this is outside the scope of this issue.

5. I completely agree that the button for boolean options looks horrible. Suggestions for a better Tk widget to use are welcome!

Finally, regarding

Bah, my original message was truncated!

I could use some help figuring out how to test with various Tk versions. I have a Mac with OSX 10.8, and I've found the "IDLE and tkinter with Tcl/Tk on Mac OS X" page[1], but I'm still not sure how to actually go about installing and running IDLE with the different versions.

Tal, I'm working on something to make that easier.

@Ned: Great! Please keep me posted.

New changeset 3f10b8009060 by Terry Jan Reedy in branch '2.7':
Issue 3068: Move idlelib.configDialog action button creation into a separate
https://hg.python.org/cpython/rev/3f10b8009060

New changeset f0e06514d67f by Terry Jan Reedy in branch '3.4':
Issue 3068: Move idlelib.configDialog action button creation into a separate
https://hg.python.org/cpython/rev/f0e06514d67f

Pushing a usable extension editor is my current Idle priority since the lack of one more or less blocks several other issues.  The two big problems with the Feb 2014 patch are the actions buttons at the bottom and the true/false options.

I moved the cureent, apparently working ConfigDialog action button code into a new method that I believe can be re-used in ConfigExtensionDialog with
    create_action_button = ConfigDialog.create_action_button
I nect incorporate this into the patch. (I pushed the change already because it makes the existing code clearer and easier to modify, by disentangling page code from button code.)

For binary options, I will use radiobutton pairs, as with ConfigDialog, if I cannot easily get a single button to look nice and work correctly.

Pending review on non-Windows systems, I believe the attached patch patch is about ready to commit (after re-enabling all tests).  As for Ned's 5 points:

1. macosxSupport.py changes are incorporated.

2. Buttons should work with re-use of the ConfigDialog code.  I altered create-action-buttons to incorporate the padding above the buttons.

5. The boolean option buttons were stretched because of 'sticky=NSEW'.  Changing that to 'sticky=W' moves leaves them sized as specified and left-justified.  Removing 'sticky=W' leaves them centered, but I think I prefer them to the left.

---

3. It is annoying that ConfigParser ignores comments when reading and deletes them (by not writing them) when saving changed options. Even if it were changed, that would not help Idle on current versions.

We could establish more option name conventions (as we already have for section names and 'enable..').  For instance, if we did not externally specify that 'enable' was bool, the file could have 'enable-type=bool'.  For parenmatch, 'style-vals=expression, ...' would indicate the allowed values. If not too many (only 2 in this case, I think), radiobuttons could be generated.  fg/bgcolor should have a color selector.  Lets make this a followup issue.

4. When changes take effect is another followup issue.  There are (at least) 3 possibilities.  Affect all open windows immediately.  Affect new windows in current session.  No effect until restart. (I think this should be avoided if possible, but I believe there are examples now).

It would be nice if ConfigDialog indicated somehow which.  If nothing else, this could be part of the missing Help (especially if specific to the current page).  Changes for the current window only should be only done by specific entries on the Option menu -- see below.

I think the proper answer depends on the option.  AutoComplete popupwait should take effect immediately.  Ditto for bgcolor, etc, for CodeContext.

On the other hand, CodeContext enable (for edit windows) should only affect new windows.  On the line-number issue #17535, I believe, we discussed the fact that the checkmark beside CodeContext on the Option menu has no relation to the current window and only refers to what will happen new windows.  My understanding of the consensus is that Option/Context should toggle and indicate the current window while the default for future windows should be changes by changing .cfg (with this editor).

Saimadhav, can you review on linux?  This is the blocker for line numbers.

A note on style: there is no need for leading underscores, so I removed them.

I think we should give each extension with options other than 'enablexx' a single 'option-help' option that gives the 'signature' of the extension.  I suggest 'option-help', rather than just 'help', as the new 'reserved' option name as being more descriptive and less likely to already be in use in 3rd-party extension. Example (that indicates my ignorance of what the options mean ;-):

option-help=ParenMatch options
  bell->bool: Ring bell on failure(??)
  flash-delay->int: Milliseconds delay before ??
  style->choice: expression, statement??

Parse by splitting on '\n', ':', and '->'.
->bool would cause the current value to be read as a bool and True/False button to be displayed.
->int would cause current value to be read as int and entered value to be checked as int
->choice would cause radiobuttons to be displayed.
->float should also be recognized

The Help button at the bottom should display information about enablexx options.

Saimadhav could not apply cfg-ext-34.diff, so uploading again, also with line-end whitespace removed. OSX test still needed.

1. Can we have more padding at the right end of the text widget? For me, it appears attached to the scrollbar.

2. Shortcut key for Configure extensions should be different from Configure Extensions. By this I mean, with the Options menu open, there is no way to open "Configure Extensions" using the keyboard.(Also see sidenote 1).

3. Is there a need for "..." after Configure Extensions? I am asking this as don't know why it was there for "Configure IDLE..." in the first place.

4. User extension config files are created even if extension config settings are not dirty. Clicking OK or Apply without changing anything creates them. 
Even if I change the setting for only 1 extension, extension config for all extensions are written to disk. This is unlike the behavior of "Configure IDLE" dialog.

5. There are a couple of places where Ok and Cancel are used. If I have understood PEP8 correctly, aren't they not following it? Should they be ok and cancel instead?

6. Is there a reason to comment out the unittest and Htest in configDialog.py?(Other than "application has been destroyed .." messages?)


Sidenote 1 : Options menu unreachable via keyboard shortcut because both format and options have "O" as the keyboard shortcut.

Sidenote 2: I am writing the review comments here as review tool does not detect all the files affected by this patch. Please confirm, so that I will post this issue to the developer list.

-- 
Regards
Saimadhav Heblikar

I'll test on OSX tomorrow or during the weekend at the latest.

However, on OSX there are three different versions of Tk available, and I'm still not sure how to test with all of them. I'll try with one, at least, and see if I can figure out how to try the others.

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. 

1. I see the problem with the text entry boxes. I will look for a fix.

2. 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'.

3. I agree and will delete ... both places.

4. 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.

5. 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.

6. 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,

1. 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.

2. changes shortcuts to _I and _E.

3. deletes '...'.
---

With respect to

4. 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__.

5. 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.

6. I intend to uncomment before pushing, but this does not affect dialog use.

New changeset 7ba47bbfe38d by Terry Jan Reedy in branch '2.7':
Issue #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 #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 #3068
https://hg.python.org/cpython/rev/111d535b52e8

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.

Patch 5 was missing the last change. Ignore it unless here is a problem with 5a

New changeset 1d708436831a by Terry Jan Reedy in branch '2.7':
Issue #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 #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 #3068
https://hg.python.org/cpython/rev/d70b70a661c6

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.
#22703 fix the behavior of Options / Code Context
#22704 rethink 'enable_xyz' system and use consistently
#22705 add 'option-help' option for doc and entry checking
#22706 write [x] and [x_config...] sections together in user .cfg
#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.

#22726  Add help to both dialogs

New changeset 395673aac686 by Terry Jan Reedy in branch '2.7':
Issue #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 #3068: Document the new Configure Extensions dialog and menu entry.
https://hg.python.org/cpython/rev/b099cc290ae9