bug#14233: 24.3; Don't constrain frame size to character multiples

["Drew Adams" <drew.adams@oracle.com>]

>  > You seem to be saying that such problems were solved long 
>  > ago (Emacs 21, no less).  But no, it is an open enhancement
>  > request to be able to compute the buffer "text" area size
>  > in pixels, as _displayed_ (in order, e.g., to fit a
>  > window/frame to it).
> 
> I suppose you mean to (1) compute the area size in pixels as displayed
> and (2) pixelwise fit the window/frame to it.  This is indeed what I'm
> doing here.

Yes.  I think (still) that my posts here have been appropriate for this thread.
If I learn otherwise then I will excuse myself for being off-topic.

I have code (in fit-frame.el) that tries to fit frames to their displayed
buffers, typically one buffer per frame.  It currently does not (cannot) take
into account the kinds of things I mentioned, which amount to all the various
ways in which what is displayed in the buffer ("text" area) cannot be modeled
exactly by just knowing the number of text lines, the frame char size, and the
maximum line length.

The fit-frame code takes into account the screen real estate used for things
like a toolbar and menu bar, but it does not yet take into account the buffer
"text" _as displayed_.  That is what the enhancement request in bug #7822 is
about.  And AFAICT it is also partly what this bug (#14233) is about.