Skip to content

IDLE - Add an extension configuration dialog #47318

Closed

Description

@taleinat
BPO 3068
Nosy @terryjreedy, @kbkaiser, @taleinat, @ned-deily
Files
  • IDLE_configExtensionsDialog.080609.patch: initial patch
  • taleinat.20140209.IDLE__Add_a_config_dialog_for_extensions.patch: updated patch (against branch 3.3; changeset 3e62c6c3977e)
  • issue3068_osx.zip: zip file with screenshots jpgs
  • cfg-ext-34.diff
  • cfg-ext-34-2.diff: extra whitespace removed
  • cfg-ext-34-3.diff: changes for Heblikar items 1-3.
  • cfg-ext-34-4.diff
  • cfg-ext-34-5.diff
  • cfg-ext-34-5a.diff
  • 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 = <Date 2014-12-04.06:27:53.295>
    created_at = <Date 2008-06-09.18:10:31.464>
    labels = ['expert-IDLE', 'type-feature']
    title = 'IDLE - Add an extension configuration dialog'
    updated_at = <Date 2014-12-04.06:27:53.294>
    user = 'https://github.com/taleinat'

    bugs.python.org fields:

    activity = <Date 2014-12-04.06:27:53.294>
    actor = 'terry.reedy'
    assignee = 'terry.reedy'
    closed = True
    closed_date = <Date 2014-12-04.06:27:53.295>
    closer = 'terry.reedy'
    components = ['IDLE']
    creation = <Date 2008-06-09.18:10:31.464>
    creator = 'taleinat'
    dependencies = []
    files = ['10561', '34014', '35559', '36840', '36904', '36921', '36928', '36931', '36932']
    hgrepos = []
    issue_num = 3068
    keywords = ['patch']
    message_count = 38.0
    messages = ['67872', '67873', '210214', '210269', '210274', '210281', '210295', '210305', '210649', '210758', '210773', '210775', '210780', '220194', '220259', '223314', '223315', '223325', '228825', '228826', '228830', '228831', '228890', '229268', '229290', '229301', '229315', '229323', '229340', '229367', '229384', '229397', '229412', '229414', '229844', '229850', '229982', '232106']
    nosy_count = 8.0
    nosy_names = ['terry.reedy', 'kbk', 'taleinat', 'gpolo', 'ned.deily', 'weeble', 'python-dev', 'Saimadhav.Heblikar']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue3068'
    versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

    Activity

    1. taleinat commented on Jun 9, 2008

      @taleinat
      ContributorAuthor

      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.

    2. taleinat commented on Jun 9, 2008

      @taleinat
      ContributorAuthor

      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.

    3. added
      type-featureA feature request or enhancement
      and removed
      type-bugAn unexpected behavior, bug, or error
      on Apr 26, 2009
    4. taleinat commented on Feb 4, 2014

      @taleinat
      ContributorAuthor

      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!

    5. terryjreedy commented on Feb 4, 2014

      @terryjreedy
      Member

      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.

    6. taleinat commented on Feb 4, 2014

      @taleinat
      ContributorAuthor

      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.

    7. terryjreedy commented on Feb 5, 2014

      @terryjreedy
      Member

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

    8. taleinat commented on Feb 5, 2014

      @taleinat
      ContributorAuthor

      (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 bpo-1529353).
    9. terryjreedy commented on Feb 5, 2014

      @terryjreedy
      Member

      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.

    10. terryjreedy commented on Feb 8, 2014

      @terryjreedy
      Member

      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?

    11. taleinat commented on Feb 9, 2014

      @taleinat
      ContributorAuthor

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

      I'll create a new patch soon.

    12. terryjreedy commented on Feb 9, 2014

      @terryjreedy
      Member

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

    13. 15 remaining items

    14. terryjreedy commented on Oct 14, 2014

      @terryjreedy
      Member

      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.

    15. terryjreedy commented on Oct 14, 2014

      @terryjreedy
      Member

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

    16. terryjreedy commented on Oct 14, 2014

      @terryjreedy
      Member

      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

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

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

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

    17. python-dev commented on Oct 14, 2014

      python-devmannequin
      Mannequin

      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

    18. terryjreedy commented on Oct 14, 2014

      @terryjreedy
      Member

      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.

    19. terryjreedy commented on Oct 15, 2014

      @terryjreedy
      Member

      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.

    20. self-assigned this
      on Oct 15, 2014
    21. terryjreedy commented on Oct 15, 2014

      @terryjreedy
      Member

      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.

    22. terryjreedy commented on Oct 15, 2014

      @terryjreedy
      Member

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

    23. python-dev commented on Oct 23, 2014

      python-devmannequin
      Mannequin

      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

    24. terryjreedy commented on Oct 23, 2014

      @terryjreedy
      Member

      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.

    25. terryjreedy commented on Oct 25, 2014

      @terryjreedy
      Member

      bpo-22726 Add help to both dialogs

    26. python-dev commented on Dec 4, 2014

      python-devmannequin
      Mannequin

      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

    27. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions