GNU bug report logs - #14233
24.3; Don't constrain frame size to character multiples

Previous Next

Full log

Message #308 received at 14233 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>
Cc: 'Eli Zaretskii' <eliz <at> gnu.org>, esabof <at> gmail.com, 14233 <at> debbugs.gnu.org
Subject: RE: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Thu, 2 May 2013 06:28:25 -0700

>  >> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.