Title: IDLE: turn builting extensions into regular modules
Type: behavior Stage: test needed
Components: IDLE Versions: Python 3.6
Status: open Resolution:
Dependencies: 24225 27173 Superseder:
Assigned To: terry.reedy Nosy List: ned.deily, serhiy.storchaka, terry.reedy
Priority: normal Keywords:

Created on 2016-05-24 02:02 by terry.reedy, last changed 2017-06-19 18:46 by terry.reedy.

File name Uploaded Description Edit
config-extensions.def ned.deily, 2016-06-14 04:47
config-main.def ned.deily, 2016-06-14 04:47
Messages (8)
msg266214 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-24 02:02
Followup to #24225, which renamed idlelib files.

Currently, an arbitrary set of 9 (of 10, if Check Module is counted as a separate feature) IDLE features are implemented as extensions.  Their menu names are as follows:
  Edit - Show Completions
  Edit - Expand Word
  Edit - Show call tip
  Edit - Show surrounding parens
  Format - Format Paragraph
  Format - Strip trailing whitespace
  Run - Check Module (same file as below)
  Run - Run Module
  Options - Code Context
  Window - Zoom Height

This issue proposes to turn these into normal features implemented in regular code. 

1. The menu entries for extensions are not included in the main menu definition file (mainmenu, previously Bindings).  Rather, they are appended when the file is read.  This is constricting.  The order of the 4 edit entries is the alphabetical order of the corresponding file names. Run Module should be at the top of the Run menu, rather than being shoved down further if and when more non-extension entries are added.

2. Each feature is a separate file, usually small to medium with one class.  This bloats the number of modules in idlelib (now about 60).  I am considering combining autoexpand and parenmatch, paragraph and rstrip, and codecontext and zoomheight (and moving codecontext to the Window menu).  They might be joined with other features from the same menu.

3. The user customization system is not very compatible with change.  The problems with extension customization and changing file names is discussed in the second half of msg266213.  If extensions are not converted, another solution will be needed.

I have not yet tested the effect of adding new key bindings to config-keys.def and config-keys.cfg.  If this causes a problem for current releases, then this is a problem we need to face.  I anticipate wanting to add other new keybindings, such as one to switch tabs when we use a notebook.
msg266221 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-05-24 03:39
I don't have an opinion on the matter, other than a reminder about the current cross-version (and cross-platform) compatibility issues with a user's IDLE configuration files as alluded to in Issue20580.  Perhaps others more familiar with IDLE's internals would have comments?
msg266778 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-05-31 20:53
The version conflict problem is why I reverted changing 'extension names' to match the new file names, before rebase collapsing my patches.  I was really glad most were in a separate patch.

Each time a feature ceases to be an extension, the (old) extension name will have to be added to a set of names ignored when calculating the set of extensions.  I will start with one until I have worked out and tested the details.
msg267575 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-06-07 00:44
The final paragraph of my initial post should have talked about config-main and features, rather than keys.

The following experiment indicates that adding new sections to config-main.def and customizations thereof to config-main.cfg should not be a problem. 

Add the following to config-main.cfg
new = True

Open IDLE 2.7 from console (python, with import).
Open config dialog.
Change item.
Close with [OK]
confirm that change is written and new section is left alone.
Close IDLE.
Repeat with 3.5.

Old versions will not see new config-main.def, so that is not an issue.

Conclusion: adding a new section that old versions ignore is much safer then adding a new value for a current section&item that old versions do read and act on, and which may refer to something that does not exist.  (This was the problem with IDLE Dark theme and would be with Unix New keyset).

The remaining issues:

4. Finding a place on the dialog itself for new customization widgets. On Font, Theme, and General tabs, there is space available either now or with some changes.  The dialog can be enlarged if needed.

5. Adding the behind-the-scenes plumbing.  This is mostly straightforward.

6. Doing minimal refactoring to make better testing easier.
That would include being able to patch in a .idlerc directory or individual user files.  The files are small and could easily fit in memory as StringIOs.

I would like to be able to set user files, open config and idleConf, open config dialog, simulate user actions on the dialog, close, and check the effect on the files.
msg268479 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-06-13 22:09
The first line of the last message should have said 'in addition to' instead of 'rather than', In the following expanded table, Key is the number of pseudoevents with configurable and fixed key bindings.  Gen is the number of General pseudoevents. (Current, from config-main.def.)

File          Menu                            Key  Gen
------------  ------------------------------  ---  ---
autocomplete  Edit - Show Completions         1,2   1 
autoexpand    Edit - Expand Word              1,-   -
calltips      Edit - Show call tip            1,2   -
parenmatch    Edit - Show surrounding parens  1,1   3
paragraph     Format - Format Paragraph       1,-   1
rstrip        Format - Strip trailing white-  -,-   -
runscript     Run - Check Module              2,0   -
runscript     Run - Run Module                same file
codecontext   Options - Code Context          -,-   2
zoomheight    Window - Zoom Height            1,-   -

My initial experiment with adding a fake event and binding in the user config-keys.cfg does not affect existing versions.  It appears to be completely ignored and does not appear on the list of configurable keys in the dialog.
msg268481 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-06-13 22:32
Ned, I reread #20580.  It reminds me that both Control and Alt are problems.  In built-in config-extensions.def, the builtin fixed bindings and one of the configurable bindings are:

autocomplete: <Key-Tab> <KeyRelease-period> <KeyRelease-slash> <KeyRelease-backslash>
calltips: <KeyRelease-parenleft> <KeyRelease-parenright> <KeyRelease-0>
parenmatch: <KeyRelease-parenright> <KeyRelease-bracketright> <KeyRelease-braceright>
runscript: <Key-F5> (configurable)

I presume that these all work fine on Macs.  Every other configurable binding uses 'Control' or 'Alt'.  When I copy configurable bindings into the file, I have to put them in each section.  Should I change each to 'Command' or 'Option' for the 'Mac' and 'Osx' sections?  Also see comment on #20580.

I am adding #27173 as a dependency, for now, because it might be easier to include the new key set before starting to add new bindings.
msg268511 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2016-06-14 04:25
Ned, from your response on 20580, there appears to be no conversion rule.  Perhap you could go throuch config-main.def and make a list of what you want for Mac and Unix respectively, if different from the current binding.  Serhiy, should anything be different for Linux?, or for your Modern Linux?
msg268517 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-06-14 04:47
Terry, I don't know that much about the history of the config files.  I do know that during framework installs of Python on OS X, the "install_IDLE" recipe in Mac/ (which ./configure uses to produce a configured Mac/Makefile) has some editing steps, using sed, to alter the IDLE .def files as they are being installed.  I'm attaching the two edited .def files as installed by the OS X installer.  And then there's the runtime munging of "Alt-" to "Option-" in GetCurrentKeySet() of idlelib/
Date User Action Args
2017-06-19 18:46:22terry.reedysetcomponents: + IDLE
2016-07-25 00:08:07terry.reedylinkissue27609 dependencies
2016-06-14 04:47:44ned.deilysetfiles: + config-main.def
2016-06-14 04:47:09ned.deilysetfiles: + config-extensions.def

messages: + msg268517
2016-06-14 04:25:03terry.reedysetmessages: + msg268511
2016-06-13 22:32:34terry.reedysetdependencies: + Modern Unix key bindings for IDLE
messages: + msg268481
2016-06-13 22:09:44terry.reedysetmessages: + msg268479
2016-06-07 00:44:46terry.reedysetnosy: + serhiy.storchaka
messages: + msg267575
2016-05-31 20:53:43terry.reedysetmessages: + msg266778
2016-05-24 03:39:50ned.deilysetmessages: + msg266221
2016-05-24 02:04:11terry.reedysetdependencies: + Idlelib: changing file names
2016-05-24 02:02:40terry.reedycreate