Fix bugs and enhance the page.

The three little frames are too much, and in the wrong order. Proposal:

Window to open at startup: O Shell O Editor
Initial size: Width [_] Height []
When run code in editor: ... (see bpo-19042 for possible change)

This compression will make room for former extension options (bpo-27099).

Tk variable startup_editor should be BooleanVar.

Size vars should be IntVars. Accepting *and saving* 'nonsense' as a size is a bug (idlfConf issues a warning when reading). Sizes should be at least 1. Changing to spinbox would ensure this. Or validate entry on each char (only accept ascii digits).

For helplist, Up and Down keys move selection indicator but *do not move the internal selection*. Delete key deletes the internal selection, not the item highlighted. Fix should be similar to fix for fontlist.

In comment for 31003, Cheryl pointed to
https://stackoverflow.com/questions/4140437/interactively-validating-entry-widget-content-in-tkinter#4140988

That prompted me to grep for 'validatecommand'. "validatecommand=is_int" is used on the extension tab. The function is at the end of the file. We just need to modify to is_pos_int and use it the same way.

is_int allows blanks. That should mean to accept the default, whatever is it. A blank should be turned back to the default. is_int checks that int(entry) does not raise value error. I believe int now accept non-ascii digits. We should check that that such pass through configparser okay. (I believe they should, as I believe it just calls int on the string read.) Or only store the ascii version. I suspect that tk wants ascii digits,

The confusion of converting between strings and non-string objects is exacerbated by tk wanting strings (which it converts to C byte encodings) and tkinter doing automatic conversions.

In 31003, Cheryl pointed out that loading helplist could use enumerate.
#2859 (review)

Common code in tests: test_helplist_item_actions functions have common code that could be factored out into a non-test_ method (especially if settings not needed for one of them is added, like setting anchor).

The listbox simulated click code in test_source_selected is copied from FontTest.test_fontlist_mouse. Make global click_listbox(item-to-add).

This may relate to bpo-31050, I would like to propose to change the name GenTab to GeneralTab. GenTab is ambiguous to GenerateTab in the first glimpse. How do you think, Terry and Cheryl ?

Given that I picked the page names without discussion, as part of quickly writing and merging the switch to Notebook (PR (to unblock the FontPage and GenPage conversion), I considered them subject to possible revision. I expect to review both the internal names and the tab labels *after* adding options from the 'extensions'.

I have considered calling the class MainPage, as it governs the options in config-main other than the font, highlight, and keys choices. (As noted before, the tab space setting would fit better on this page.)

Given that you have seen and used the dialog and its five tabs, is 'genpage' in the sequence 'fontpage, highpage, keyspage, genpage, extpage', which occurs 3 times in create_widgets(), really ambiguous to *you*? Or do you just not like it? Would you prefer MainPage?

I don't like the name "gentab". There is a "genobject.c" in source code but stand for "generator object". In the code, both docstring and the name didn't mention "General", it only mention at note.add(self.genpage, 'General'). That is why I got ambiguous when I look back to the code.

Or maybe it just because I'm not familiar for the abbr., I take a search and found that in US Army that General abbr. is Gen.

---

I'm a +0 of MainPage, since in the page, it used for general setting. I'm not sure about this changed.

It does not matter for users what we call the class. MainPage reads a bit smoother than GenPage. I have also considered renaming HighPage as ColorPage and relabeling the tab 'Colors'.

The above covers at least 2 issues. bpo-31306 covers changing Vars and testing user entries.

PR3239 Splits the General tab into 3 sections: (shell and editor) window preferences, editor preferences, and the help sources. Charles: the autocomple and parenmatch options go in window preferences, as they apply to Shell also. The reformat and context options are editor only and go in that section.

'autocomplete and parenmatch' (in that order). Code context should be last in the editor section.

New changeset 390eadd by Terry Jan Reedy in branch 'master':
bpo-31051: Rearrange IDLE condigdialog GenPage into Window, Editor, and Help sections. (bpo-3239)
390eadd

New changeset 87c5024 by Terry Jan Reedy in branch '3.6':
[3.6] bpo-31051: Rearrange IDLE condigdialog GenPage into Window, Editor, and Help sections. (GH-3239) (bpo-3240)
87c5024

Looks like this is partially done. Lacking tests only?