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

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

>  >> But I obviously agree with you that modifying a specific
>  >> frame's parameters via `modify-frame-parameters' should
>  >> never affect other or future frames.
>  >
>  > Including parameter `font'?
> 
> Including parameter `font'.
> 
>  > Setting face `default' (and thus the default font) is akin 
>  > to setting (part of) `default-frame-alist' - it is expressly
>  > intended to determine future frames.
> 
> That's what I would expect.
> 
>  > `modify-frame-parameters' has the advantage that it is 
>  > simple to use.  And there is really no more conflict inherent
>  > in `modify-frame-parameters', because of parameter interdependence,
>  > than there is inherent in `default-frame-alist': You can define
>  > that option value in a way such that various parameter settings
>  > collide also, I imagine.
> 
> Yes.  Throughout, I've been using `modify-frame-parameters' only as an
> example.  Evaluating `initial-frame-alist' and `default-frame-alist'
> runs precisely into the same problems and should be fixed the 
> same way.
> 
>  > Not necessarily, or not necessarily in lock step.  A user 
>  > could want to zoom the font but not zoom the menu bar or tool bar
>  > (or vice versa).
> 
> So the zooming function should accomodate that.

Yes to all that you said - we agree.