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

[martin rudalics]

>> I see.  It's probably for the sake of `menu-set-font' which calls it
>> with t as third argument.  And `set-frame-font' has
>>           (frame-list (cond ((null frames)
>>                              (list this-frame))
>>                             ((eq frames t)
>>                              (frame-list))
>>                             (t frames)))
>> so any non-t value will not affect other existing frames.  But any
>> non-nil FRAMES value will "alter the user's Custom setting of the
>> `default' face, but only for font-related attributes" whatever that
>> means.  Maybe it should do that iff FRAMES equals t.
>
> Maybe.  Or maybe KEEP-SIZE is not really needed?  (Dunno.)

I don't see what KEEP-SIZE has to do with this.

>>  > But see my earlier msg where I mention that I do not in
>>  > fact see the future-changing behavior that is advertised
>>  > for new frames.  Do you see it?
>>
>> If you gave me a recipe for what to try.
>
> I did, starting from emacs -Q.  Please see my msg of 2013-04-28:
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14233#272.  Let me know if
> something in that recipe is not clear.

Honestly, I don't understand the customization stuff you mention there.

>> Do you see a changed default face at least when you call that function?

Yes.  That is, when I invoke `menu-set-font' (which calls
`set-frame-font') I see that the default face changed.

> Please see what I wrote.  I detailed what Emacs tells me about face `default',
> which seems to depend on the current frame and something else.  AFAICT, it 
does
> not work as advertised, at least on MS Windows.

When I change my font via `menu-set-font' to

"-outline-Lucida Console-normal-normal-normal-mono-21-*-*-*-c-*-iso8859-1"

I get as (face-font 'default) that value and when I do C-x 5 2 I get a
new frame with precisely that font.

>> Here on MS Windows the Emacs 24.3 fringe zooms along with the text.
>
> Really?  Here it does not, and never has, ever since fringe has existed (Emacs
> 21).

Using `menu-set-font' I can produce with emacs 24.3

(frame-parameter nil 'font) ; =>
"-outline-Lucida Console-normal-normal-normal-mono-16-*-*-*-c-*-iso8859-1"
(window-fringes) ; =>
(10 10 nil)
(frame-parameter nil 'font) ; =>
"-outline-Lucida Console-normal-normal-normal-mono-21-*-*-*-c-*-iso8859-1"
(window-fringes) ; =>
(13 13 nil)

Whether this actually results in a visible change is a stochastic
phenomena whose behavior I can't describe yet.  Maybe I never will be
able to do so.  But eventually the size of at least one fringe changes.

> I change only the `font' parameter, substituting a different number for the
> height/size in the font string.  The fringe remains the same width.  I can
> shrink or enlarge the font (and hence the frame) more and more, but the fringe
> width stays the same.

Maybe some rounding effect?  Also, as I mentioned, fringe changes get
sometimes miraculously delayed.

>> The scrollbar currently doesn't - but it has larger increments IIRC.
>
> I believe I was told that this is a toolkit thing (or something like that).  
The
> scrollbar changed size when you changed the font size prior to Emacs 21.  
Since
> 21 it has not changed size along with the font.

I wouldn't be that sure.  You might have to play around some time with
very large sizes.  There's all sorts of rounding effects when adjusting
these parameters.

> I just now retested all of this (scroll bars, fringe), from emacs -Q, in Emacs
> 20, 21, and 24.  Changing only frame parameter `font', and only wrt the
> height/size, has the effect I just described, in MS Windows XP (SP3).

I could experiment further but it's too annoying because my frame always
gets larger than my screen.

> My concerns, which I'm sure you understand, are these:
>
> a. `modify-frame-parameters' should not be changed so that it affects future
> behavior.

My concern is that it should be changed.

> b. Changing the `font' parameter of a frame should also shrink/enlarge the
> frame, as it does today.  That is, shrink/enlarge in terms of screen size
> (pixels), but not in terms of number of lines/cols.  IOW, the frame size 
should
> keep the same number of lines/cols.

I'd prefer the frame + external objects to keep the same number of pixels.

> Wrt (b):
>
> 1. Keeping the same number of lines/cols when the `font' size changes does not
> mean that the frame must be an integral number of lines/cols, AFAIK.  I too 
want
> frames to be sizable in terms of pixels.  All I am saying for (b) is that the
> lines/cols should remain the same when changing the `font' size, as is the 
case
> now.  Numbers of additional pixels can be different.

OK

> 2. If someone needs/wants to be able to change the `font' parameter without
> changing the frame size, I am not against providing such an option somehow.
> That was apparently what was done for `set-frame-font' by adding the new
> optional parameter KEEP-SIZE.  So presumably this want/need has already been
> satisfied.

But not for `modify-frame-parameters'.  And that's the problem.  When
you change the frame size you have to contact your window manager, wait
till it gets back to you, and then you have to fit all your objects into
the space alloted by the window manager.  Now, obviously you have to do
all these things also when you just resize the frame.  But in that case
you didn't change the font.  Or if you did, you did it without intending
to change the frame size with it.

An action like changing both frame size and font in some coordinated
sense is per se complicated and I'd rather do it only when not changing
anything else.  And that's why I don't want this to be handled by
`modify-frame-parameters' where one can change any other parameter as
well.  There should be one special function to change font and frame
size in a coordinated manner and when people call that function, for
example, for zooming, they should not set other frame parameters at the
same time.  And if they do, they might be on their own.

> My impression is that perhaps in the desire to allow better sizing of frames
> pixelwise you would abandon the fact that resizing the `font' resizes the 
frame
> accordingly so that the number of displayed lines/cols remains the same.
>
> I don't think that should be necessary.  I understand that pixels not directly
> related to text display might need to be different for different `font' (hence
> frame) sizes.  But I think we should be able to keep the same lines/cols
> displayed.

But you probably agree that we should not change the pixel size of a
maximized frame.  In any case, my concern is to make frame parameter
handling via `modify-frame-parameters' predictable, in some sense at
least.  Currently, I'm completely lost in a jungle of things that get
processed in some incomprehensible fashion.

> Now, when embedded images are involved, for example, since they are not 
related
> to the `font' size, they will not shrink/enlarge along with the `font' and
> frame.  So in that case the lines/cols would not be the same.  Likewise for 
tool
> bars etc., as is already the case today.

Are you sure?  What if toolbars have accompanying text?

> Changing the frame `font' size zooms only the text.

Not here.

> Other forms of zooming
> would need to be combined with that to also shrink/enlarge non-text things.
>
> But wrt text display it is important (to me anyway) that the frame try to show
> the same text display, regardless of its size: same lines/cols, which means 
also
> same overall text appearance.
>
> If someone wants to zoom the text of a buffer without also shrinking the 
frame,
> s?he can use `text-scale-adjust'.

I don't care about the functions for achieving some specific effect.  I
care about the basic functionality of `modify-frame-parameters'.

> Being able to calculate the pixel size needed to display a given buffer 
portion,
> which I hope will also be provided by this bug fix, is something I've been
> hoping for for a long time.  But it is independent, I think, of trying to let 
a
> frame keep the same number of displayed lines/cols when shrunk/enlarged.

Mostly so, I hope.

martin