I consider it a bug for *IDLE* to place and size windows so that the bottom of the window is hidden.  (If users, perhaps temporarily, move a window down so that the bottom is hidden, that is their business.)

This is especially bad for the Settings dialog because the Enter and Escape keys are not bound to the Ok and Cancel handlers, as with at least most of the other dialogs.  This should be easy to fix.

The general problem in preventing over-sizing and misplacement is that, 
as far as Tal and I know, tk will only tell us the full size of a particular screen, not the current, usually reduced, view size.

Until about a month ago, ZoomHeight used platform-specific expressions from long ago that do not, in general, work now.  For issue #37039, Tal's solution was to 'calibrate' each screen the first time a window is zoomed on a screen in a session.  The window is maximized, the pixel height is saved, and the window is narrowed to what is was.  The saved height is used for subsequent zooms.  Maximizing works because the OS + tk maximize to the current view size, depending on the current screen settings.

I suggested then the possibility of IDLE opening with a maximized splash screen.  Tal objected that this a) did not solve the problem of multiple screens, and b) would unnecessarily bother people who never zoom.  But zoom height is not the only feature that needs this knowledge.

On my machine with 45 line shell/editor windows, Shell is initially placed too low if I open IDLE one particular way.  I'll leave that to another issue.

For the config dialog, there is a geometry bug independent of the font sample content.  Even if the box is cleared, the dialog expands with font size.  Fixing this is also a priority.

To completely solve geometry issues, we again need to know the screen's view height.  If not available, we would have to momentarily maximize the dialog as now done with zoom height.

The height of the Setting dialog is the maximum of the page sizes.  For normal font sizes, the font page is the shortest of the first 4, meaning that is has the most extra space.  The Highlight and General pages seem to be equally tallest.  So adding settings to the latter will increase the minimum size.

For 3.7.3, the dialog already fills the view height between menu line and icon bar on my Macbook Air.  But it is opened a quarter of the way down, so that a quarter of the dialog is covered.  This is another geometry bug.  On this machine, the dialog should be opened flush up against the app menu.  But hard-coding that for all machines would likely annoy most people who do not need that positioning.

I am worried that the addition of two more items to the General page, for zoom height and line numbers, will make the dialog too tall for the available space.  When 3.8.0a3 is released, I will check. 

I am thinking of moving indent size, revised, to the General page and moving Additional Help Sources, possibly flattened a bit, to the Font page.  Perhaps we should try to make the pages wider rather than taller.