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

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

> I'd rather see that text is text.  Fringe and scrollbars 
> should not be included, nor should margins or borders.
> Non-text portions should be able to have any width/height
> in pixels.  This includes the native toolbar.
> 
> But I'd prefer if the text part is resizable only in terms of 
> lines/columns. An exception to this is tiling window managers
> and fullscreen behaviour.

There are other exceptions too, besides tiling WMs and fullscreen.  The "text"
area can include images, boxed text (which can increase the apparent char
height/width), fonts of different sizes in the same line, and various other
display artifacts/properties.

IOW, "Text" and the text area are not just about lines and columns anymore, at
least when it comes to resizing a window or frame to fit it.

Users should be able to calculate the needed "text" area to display a given
buffer portion well (i.e. to fit it).

It is good to keep each area of a frame and window separate in terms of its
treatment (toolbar, menu-bar, fringe, text area, etc.).  Users (and higher-level
predefined functions) can then combine them as needed when calculating the
desired size etc.

IOW, let programmers deal with each such area individually when they need to.
If possible, do not give them just an overall knob to turn and force them to
rely upon Emacs to juggle all of the parts well and make a good compromise
automatically under the covers.

For a given application it _could_ make sense to privilege the display of the
first or last text line's height fully and sacrifice a couple pixels from the
full height of a toolbar or a fringe or whatever.

Emacs can provide good overall compromises, but it is still good to give users
control over the combining for the cases where they need it.

Perhaps (dunno) even give users functions/parameters to let them explicitly pad
chosen display areas with "extra" pixels and trim pixels from other display
areas.  IOW, the kinds of thing that you might be doing automatically to make
things work right.  That would not be the first thing they would do, but it
might still be useful to be able to do.  Dunno.

----

FWIW, I have not followed this thread well, but I will probably be interested in
the outcome.

Another meta-comment would be that this project is bound to be difficult,
perhaps long, and involve some compromises.  Let's try to attack it
progressively, in stages.  A goal should remain that we not break what works now
(the line/column sizing etc.) as we advance.  (Preaching to the choir, no
doubt.)

Thanks for working on this.