[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Terry J. Reedy added the comment:

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

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Terry J. Reedy added the comment:

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= 
expand-word= 
force-open-calltip= 
format-paragraph= 
flash-paren= 
run-module= 
check-module= 
zoom-height= 

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Terry J. Reedy added the comment:

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 = 
expand-word = 
force-open-calltip = 
format-paragraph = 
flash-paren = 
run-module = 
check-module = 
zoom-height = 

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.

--
dependencies: +IDLE: turn builting extensions into regular modules

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +serhiy.storchaka -westley.martinez

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Charles Wohlganger]

Changes by Charles Wohlganger :


--
pull_requests: +3253

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
assignee:  -> terry.reedy
versions: +Python 3.7 -Python 2.7, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Ned Deily]

Ned Deily added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Terry J. Reedy added the comment:

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Ned Deily]

Ned Deily added the comment:

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.

--
versions:  -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Mark Roseman]

Mark Roseman added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Mark Roseman]

Changes by Mark Roseman :


--
nosy: +markroseman

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--
versions: +Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Ned Deily]

Ned Deily added the comment:

"Correct?"

Yes

"And you would like to change this?"

I think it should be considered, yes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Ned Deily]

Ned Deily added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--
stage:  -> test needed
type:  -> enhancement
versions: +Python 3.5 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Terry J. Reedy added the comment:

I closed #1517993 in favor of this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Westley Martínez]

Changes by Westley Martínez :


--
nosy: +westley.martinez

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Terry J. Reedy]

Terry J. Reedy added the comment:

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

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20580] IDLE should support platform-specific default config defaults

[Ned Deily]

New submission from Ned Deily:

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  events to  events, since none 
of the OS X Tk implementations support  events (see Issu
 e20579).  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]
...

--
components: IDLE
messages: 210816
nosy: ned.deily
priority: normal
severity: normal
status: open
title: IDLE should support platform-specific default config defaults
versions: Python 2.7, Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com