Terry J. Reedy added the comment:
There is a reason that I said, in msg266221, that I would experiment with
moving 1 feature ;-). I knew from past experience that changing anything that
affected user configuration would have to consider the effect on previous
releases. A total 'clean break' now would mean not a Py2 versus Py3 set of
files but a Py3.6.2- versus a Py3.6.3+ set of files and I will not do this.
But it is OK with me that you plunged ahead to learn for yourself. I expect to
use most of what you have done. I would like to get this into 3.6.3, whose
release candidate is scheduled for late September. But see below. That I one
reason why I have focused for the last month on getting config and configdialog
ready for changes.
When I said, in msg298982, that the extensions tab has 'a separate system for
handling user changes', I meant for putting user changes into idleConf.
IdleConf itself handles the 2 sets of 4 files (or the 4 pairs) uniformly. I
intend to remove that separate system *before* working on this. The changes
instance of the new config.OptionChanges is already initialized with an
'extensions' dictionary that corresponds to the idleConf.userCfg['extensions']
instance of IdleUserConfigParser.
So, *do not change your patch to use the separate system*! I expect that we
should just need to replace 'main' with 'extensions' in something like
"changes.add_option('main', 'AutoComplete', 'popupwait', value)".
Changes that impact users should have a net user benefit, either directly or
indirectly. Moving menu entries, making the menu different in different
releases, will bother some people, but I think a few changes will be justified.
Moving the tab where non-key options are displayed and changed also makes
successive releases different. The (potential) benefit is that it will be
easier to select and check entries. I just discovered that one can currently
set editor width, for instance, to the string "nonsense"!. So the other tabs
are also deficient. The benefit needs to be that entries, both existing and
added, *are* checked. Moving the file where non-key options are *stored* has
no user benefit to counter the severe incompatibility problem. Satisfying my
aesthetic sensibilities is not good enough to justify the breakage.
Extension key-binding options are already displayed on the keys tab. The issue
is saving *all* key changes to the key file. The user benefit is to make it
easier to design a new custom keyset. Some people do this by copying a section
into config-keys.cfg or a separate file and editing it in an editor with enough
lines to see everything. This seems easier than laboriously scanning the box
showing 10 bindings at a time and changing one at a time with the popup. But
the editor method misses the extension binding. In any case, even after adding
an error check from a 2009 submission, there are 9 remaining keys issues and as
many potential issues on my list. Improving the keys tab for all bindings is
as important as moving the storage of some.
Changing existing non-buggy behavior is much more problemmatical than fixing
buggy behavior or adding new behavior. So we could defer the above changes to
3.7. But I don't like that either. It deprives 3.6 users, which there will be
for several years, of the benefits. Diverging the files would make backing
other improvements to 3.6 harder and less likely.
This issue is worse for the big change to tabbed windows. Proposed solution:
make tabbed windows a 'beta preview' option for the 3.6.x release after a
minimal version is ready. (There would be the option of leaving the option in
3.7, though perhaps as opt-out.)
The same could be done with the changes in this issue. Make them opt-in in
3.6. Add 'Preview' before 'Help' with two items on the drop down:
'Explanation', and 'Selected'. Explanation would popup a text view window.
Selected would set a variable.
I am working on removing from ConfigDialog a class for each tab. When that is
done, we put the opt-in changes for this issue in a subclass of each. Then
ConfigDialog
----------
nosy: +louielu
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27099>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
