There is a need for IDLE to provide different default settings depending on which platform it is running, e.g. Windows, OS X, or other UNIX.  That need need has been most acute for OS X where, for various reasons, tailoring of default key bindings for IDLE commands and extensions is either necessary or desirable to conform to platform user interface guidlines or, more importantly, platform-specific Tk behavior.  For OS X, that customization is provided in part by brute force editing of the config-main.def and config-extensions.def in Mac/Makefile target install_IDLE which is run during installation of framework builds.  While that works for that case, it is brittle and opaque and does not help for non-framework OS X installs or when running from a build directory.  And it doesn't help for other platforms.  Other OS X customization is done at run time to convert any <Alt-Key-> events to <Option-Key-> events, since none of the OS X Tk implementations support <Alt-Key-> events (see Issue20579).  It would be better to provide some way to specify these various conditional settings directly in config-main.def and config-extensions.def themselves, perhaps with platform-specific sections in the files that would be merged with and override the current general sections.  For example, in config-main.def, a possible implementation might be:

[Keys]
default= 1
name= IDLE Classic Windows

[Keys-OSX]
name= IDLE Classic OSX

[Keys-Unix]
name= IDLE Classic Unix

This might also be used to support different options for different versions of IDLE since today all versions by default share the same user configuration files.

[Keys]
...

[Keys-2.7]
...

[Keys-3]
...

From what you have said here and on the other issue, reality has outgrown the current customization methods. If Python, Tk, and Idle were to run on Windows RT, I presume a different configuration would be needed than for normal desktop.

Any new scheme used in the config files should allow the config dialog to still work sensible. If a current value displaying in the dialog come from a special section, then I think user changes should propagate back to that section and not the generic setting.

I closed #1517993 in favor of this.

I am not completely sure what you are asking. Config-keys.def has 4 Idle Classic sections, one each for Windows, Unix, Mac (still needed?), and OSX. On my Windows install, the one for Windows is preselected. I have presumed the the appropriate selections are made for other systems. If so, your opening sentence 'provide different default settings depending on which platform it is running,' would be true already. If not, that would be a bug.

ConfigHandler.IdleConf.GetCoreKeys has hard-coded backups that probably work on Windows and Unix but not Max/OSX. I don't know if the 'Alt' to 'Option' replacement is applied to these are not.

If 'Alt' to 'Option' is insufficient for key bindings in config-extensions.def, I don't know what the answer is. Non-mac extension writers are unlikely to know what else to do.

Can any of the editing of Mac/Makefile be moved into runtime?

In "all versions by default share the same user configuration files", does versions mean 2.7, 3.4, 3.5 on one machine? If so, the statement describes a great feature that I would not change. If 'versions' means Windows Idle on one machine and OSX Idle on another machine, then the statement make no sense to me as we do not deliver user configuration files. If you mean multiple OS versions on the same machine, and it is possible to login as the same user with different Oses (I have no idea if this is so), then I could see a problem.

"I have presumed the the appropriate selections are made for other systems."

As far as I know, there is nothing in IDLE itself to do that.  As I noted earlier, there is a kludge in the Mac Makefile to edit config-main.def and config-extensions.def during installs of OS X framework builds.  That doesn't help non-framework builds on OS X nor any builds on other non-Windows platforms.  They default to the values in the checked-in versions, which default to Classic Windows.

"Can any of the editing of Mac/Makefile be moved into runtime?"

If you mean move the editing of config-main.def et al into IDLE itself, sure. That would address the issue of defaults for non-framework builds for OS X and could be extended to other non-Windows cases, assuming it was desirable to change the current defaults (I don't know if that is the case).  On the other hand, that would only help when a user starts IDLE without existing .idlerc/*.cfg files, e.g. the first time the user uses IDLE and the first time was with a newer version of IDLE that had this feature.  Presumably existing .cfg files would not be edited.

"In 'all versions by default share the same user configuration files', does versions mean 2.7, 3.4, 3.5 on one machine? If so, the statement describes a great feature that I would not change."

It means all versions of IDLE, not just the latest releases of branches undergoing active maintenance.  We can't assume that the user is just using those.  For example, various versions of IDLE are shipped with many OS's or by third-party package managers; Apple ships three versions of Python - 2.5, 2.6, and 2.7 - with the current release of OS X.  That means all of those versions of IDLE and any others (newer or older) that the user has installed are all sharing the same configuration files.  Is it reasonable to guarantee compatibility across all of them?  And does it make sense to provide the same list of recent files for all versions, especially across Py2 and Py3?  I don't think there is one right answer to these questions but today users have no choice.  As IDLE continues to be enhanced and changes are made, the probability of possibly catastrophic incompatibilities will no doubt increase.  I don't know if there are any today.  I think it would be better to eliminate that risk.  There certainly are other use cases, i.e. where home directories are shared across machines of the same OS type; I think the above considerations apply to nearly all of them, as well.

You appear to be saying that even though some of the per system defaults you want are present, they are not automatically used, but users must go into the options dialog to select bindings other than Windows. Correct? And you would like to change this?

The odd situation we have is that default configuration in idlelib is specific to the installation, but the same for all users, whereas user overrides are specific to the user, but the same for all installations. Thanks for the reminder that we need to be careful. I will consider this before we change the location of format width in #20579.  As I say there, some changes will need Idle What's New entries and perhaps a reminder to read it in the signon message, and access from the help menu.

"Correct?"

Yes

"And you would like to change this?"

I think it should be considered, yes.

While I like the fact that my font choice is used by 3 installed and 4 built pythons, I am beginning to see possible version problems.  In #5594 I propose adding a Startup tab to Idle preferences, but doing so will require carefully checking that the corresponding all-release user config file works on releases without and with the new tab.

Before creating another layer on top of the existing layers of configuration handling, can I suggest for now at least just hard-coding the few things that are needed in the code itself? 

For example, in configHandler.py, after calling LoadCfgFiles, we could call a routine like, e.g.

    def AdjustPlatformDefaults(self):
        if sys.platform == 'darwin':
            self.defaultCfg['main'].set('Keys', 'name', 'IDLE Classic OSX')
        ...

An appropriate comment could be added to config-main.def about this default option being overridden.

That would allow getting rid of the Makefile hack.

See Issue26417 for further discussion about the OS X specific tailoring of IDLE config files and changes to the 2.7 Makefiles to better match the 3.x Makefiles to reduce the risk of inadvertent platform differences.

Ned, looking at config-keys.def, the Mac and Osx sections have a mixture of 'Command' and 'Control'.  I have the impression from what you wrote above that every 'Control' should be 'Command'.  Why are the sections as they are?

"I have the impression from what you wrote above that every 'Control' should be 'Command'."

I'm not sure where I gave that impression but, no, the default IDLE keyset on OS X has command accelerators with Command- modifiers and some with Control- modifiers, as is typical of OS X applications.

A. In 3.6+, the [Keys] section of config-main.def reads

[Keys]
default= 1
name=
name2=
# name2 set in user config-main.cfg for keys added after 2016 July 1

The name is no longer 'IDLE Classic Windows'.  Instead, if default is left true, the actual default is selected in config.py with

    @staticmethod
    def default_keys():
        if sys.platform[:3] == 'win':
            return 'IDLE Classic Windows'
        elif sys.platform == 'darwin':
            return 'IDLE Classic OSX'
        else:
            return 'IDLE Modern Unix'

This change accompanied the addition of the Modern Unix keyset.

If the makefile for 3.6+ still has the sed command to replace 'Windows' with 'OSX', you can remove it.


B1. #27099 is moving all built-in user-configurable key defs in config-extensions.def to individual keysets in config-keys.def.  These are:

force-open-completions = <Control-Key-space>
expand-word = <Alt-Key-slash>
force-open-calltip = <Control-Key-backslash>
format-paragraph = <Alt-Key-q>
flash-paren = <Control-Key-0>
run-module = <Key-F5>
check-module = <Alt-Key-x>
zoom-height = <Alt-Key-2>

According to my reading of
https://hg.python.org/cpython/rev/13826ff147e4
the makefile changes each 'Alt-Key-' to  'Command-Key-', with an additional change for zoom-height.  We can instead put the correct keys in the Mac and OSX keysets.

B2. Serhiy: Are any of the above 'wrong' for Unix/Linux?  Or should any alternatives be added?

B3. Custom keysets will initially be missing the new defs.  IdleConf currently replaces missing values with the windows values (hard-coded into the file).  I think it should instead get replacements from the OS-specific default -- and perhaps check for conflicts.  Then it should, if possible, write-back the complete keyset.


C. There are various proposals to add new customizable key definitions for existing and new features.  The issues in B, customizing default keysets and augmenting custom keysets, will come up repeatedly.  When I decide to add a new key definition, I could nosy you two, Ned and Serhiy, or add a note to this issue.

I miswrote.  'Alt' becomes 'Option'. The new keybindings to be added to Classic Mac and Classic OSX in PR2494 are the following.

force-open-completions= <Control-Key-space>
expand-word= <Option-Key-slash>
force-open-calltip= <Control-Key-backslash>
format-paragraph= <Option-Key-q>
flash-paren= <Control-Key-0>
run-module= <Key-F5>
check-module= <Option-Key-x>
zoom-height= <Option-Key-0>

This leaves B3, replacing missing definitions in user files with appropriate defaults.  The only solution I can see is to use the system-appropriate builtin from idlelib/config-key.def as the default instead of the current hard-coded keyset.  If that file cannot be read properly, either from disk fault or user editing, I think it better to stop than to use a keyset that will not necessarily be usable.

Ned, config.py currently has

    def GetCurrentKeySet(self):
        "Return CurrentKeys with 'darwin' modifications."
        result = self.GetKeySet(self.CurrentKeys())

        if sys.platform == "darwin":
            # OS X Tk variants do not support the "Alt" keyboard modifier.
            # So replace all keybingings that use "Alt" with ones that
            # use the "Option" keyboard modifier.
            # TODO (Ned?): the "Option" modifier does not work properly for
            #        Cocoa Tk and XQuartz Tk so we should not use it
            #        in default OS X KeySets.
            for k, v in result.items():
                v2 = [ x.replace('<Alt-', '<Option-') for x in v ]
                if v != v2:
                    result[k] = v2

        return result

This already did or would have done what the Makefile did.  The comment suggests that maybe you suggested that 'Alt' to 'Option' is not always correct.  What say you now?