Screen real estate utiliziation

[Daniel Brockman <daniel@brockman.se>]

Hi list,

Under a window system, Emacs frames want to be resized in
certain increments.  The window manager usually respects this,
so an Emacs frame is usually w * W pixels wide and h * H
pixels tall, where w and h are integers and W and H represent
the character width and height, respectively.

This usually results in each Emacs frame displaying a whole
number of lines of text.  But I've got my `mode-line' face
set to make it draw a two-pixel border around the mode line.
This means that my Emacs frames are not displaying a whole
number of lines of text.

Assuming plain-text buffers, I always see only part of the
bottom-most line of the bottom-most window of each frame.

This in itself doesn't bother me.  What does bother me is
what happens when Emacs is forced to be a certain height.
If an Emacs frame that is displaying a partial line
immediately above the mode line is forced to be a single
pixel taller, that one pixel goes to waste.

This screenshot demonstrates the phenomenon:
<http://www.brockman.se/software/emacs/dead-space.png>

Notice the dead space at the very bottom of the frame.
Those ca. 10 pixels could be put to better use by extending
the main window height by 10 pixels, so that the dead space
would be eliminated.

The same thing happens for the frame width (in the above
screenshot, I believe there are two pixels of dead space to
the far right), but that doesn't bother me as much.

You can reproduce this easily by bringing up a buffer with
large headings, such as the Info system, and then maximizing
the Emacs frame in, e.g., GNOME.  Unless you are very lucky
and the pixels add up just right, you should be able to
observe the partial line and dead space.

I have been strolling through the source code trying to
figure out how difficult this would be to fix, but I'm not
sufficiently familiar with the code so I have to give up.
I'd appreciate it if someone who knows this code better
could evaluate the difficulty of fixing the problem.

Please let me know if any part of the problem is unclear.


Best regards,

-- 
Daniel Brockman <daniel@brockman.se>