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

[Drew Adams]

>  > Emacs 24.1 added this, AFAICT.  It added optional 3rd arg 
>  > FRAMES for `set-frame-font'.
> 
> 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.)

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

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

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.

> I can only repeat that I won't change the behavior of
> `modify-frame-parameters' wrt the font parameter if you don't want it.

Thank you.

> But this means that the interaction of `modify-frame-parameters' with
> window managers will remain as it is now.  I won't change its behavior
> wrt fringes or scrollbars only.

I can't speak to that.  I'm not sure what changes wrt fringe/scrollbars you had
in mind.

>  > The scrollbars and the fringe are not changed when the 
>  > frame font size is changed.  Not on MS Windows, at least.
>  > Prior to Emacs 22, the scrollbars (but not fringe) were
>  > zoomed along with the text.
> 
> 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).

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.

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

>  > The big thing that doesn't belong mixed in with the others 
>  > is changing the appearance of future frames.  Changing a frame
>  > parameter in one frame should not affect future frames.
> 
> Do I understand correctly that `modify-frame-parameters' never affects
> future frames?

I believe that is correct.  It affects only its targeted frame.

>  >> Maybe because when it creates a new frame Emacs has it inherit
>  >> certain things from the selected one?
>  >
>  > Certain things are inherited from the selected frame.
>  > But you want to change which things are inherited.
> 
> Why do you say such a thing?  Apart from the current buffer I wouldn't
> even know what is inherited.

I guess I misunderstood your proposal, sorry.

>  > And now you bring in "the selected one".  In the proposal, 
>  > IIUC, ALL future frames would have their font size changed,
>  > not just those frames created when the altered frame happens
>  > to be selected.
> 
> If "the proposal" stands for my earlier suggestion to use
> `set-frame-font' instead of `modify-frame-parameters', then I 
> obviously withdraw that suggestion provided we cannot turn off
> the impact on future frames.

Great.  Let's not argue about what might have been proposed or misunderstood as
having been proposed.  What is important is what the behavior is and will/should
be.

My concerns, which I'm sure you understand, are these:

a. `modify-frame-parameters' should not be changed so that it affects future
behavior.

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.

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.

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.

>  > I consider it a mistake.  But I'm not trying to fix/change 
>  > `set-frame-font' here.  And as I said, I do NOT even SEE the
>  > (misguided) future-changing behavior that its doc claims for it.
> 
> This would mean we have two bugs already.
> 
>  > My concern is to keep `modify-frame-parameters' doing the 
>  > right thing wrt parameter `font'.
> 
> And my concern was to change the conception on what the right 
> thing wrt parameter `font' is.

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.

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.

Changing the frame `font' size zooms only the text.  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'.

>  > If someone wants to get the affect you prefer then s?he can use
>  > `set-frame-font' with non-nil KEEP-SIZE (but I think that
>  > function might need to be "fixed" so that actually works).
>  >
>  > There is no good reason to change `modify-frame-parameters' so
>  > that such odd behavior (not even the default for `set-frame-font') 
>  > becomes the new norm.
> 
> That "odd behavior" is the standard here with applications 
> like Firefox, Thunderbird, ...  The fact that Emacs is special
> doesn't give me a valid reason to call the rest of the world odd.

OK, yes, let me say that both behaviors should be possible.  Some people,
sometimes, will want the frame to stay the same size when they shrink/enlarge
its text.  Other people, other times, will want the frame to shrink/enlarge
along with the text.

I am generally in the latter camp, because I save screen real estate when I
shrink frames (including to thumbnail size).  I use many frames, often visible
at the same time.  Someone who uses frames the way one might use tabs in a web
browser, i.e., showing only one frame at a time, will prefer a different
behavior, no doubt.

We should be able to accommodate both use cases.

If you looked at my screen now, you would see several frames at different font
sizes and thus different frame sizes.  Some are even just thumbnails - almost
like icons.  I dynamically enlarge particular frames that I want to focus more
on, while others are shrunk to different degrees so I can still see their text
clearly but they do not take up as much space.

I do not claim that my use of Emacs frames is a common one, but I do know that
there are some others who use it.

BTW, I will note that even when I enlarge text size in a web browser I often
also (manually) increase the browser size so that the text lines fit better.
Likewise, when I decrease the text size I often narrow the browser window, so
the lines are shorter.

There is a reason that newspapers (which are wide) divide the text into columns,
even when there is only one article on the page: long lines are harder to read.

Line length is typically determined by browser width, and for the same reason
that newspapers shorten lines by creating columns, it can make sense for a user
to resize the browser window when s?he changes the text size.

Do many users bother to resize their browser when they resize text?  Dunno,
probably not.  But I do, quite often.

(Many readers probably never resize browser text.  And many browser pages are in
fact divided into columns.  And many other browser pages prevent you from
resizing the text at all.)

The point here is that with a web browser you have to perform two separate
operations: resize the text and then resize the window to best fit the new text
size.

In Emacs, zooming the frame font is the same as zooming the frame: they move
together in a coordinated way, so that what you see remains pretty much the
same: same lines/cols, same line width (in terms of number of chars).

Best will be to let users (a) have this convenient, coordinated behavior or (b)
optionally choose, for a *given frame* or *generally*, the typical web-browser
behavior of keeping the frame size fixed when zooming.

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.

Similarly, not constraining a frame size to char multiples (this bug report's
subject) is, I think, pretty much independent of whether a frame tries to keep
the same lines/cols displayed when zoomed.

Yes, exact fitting of a frame to a particular pixel size will often forego
maintaining the same number of displayed lines/cols - of course.  That is
something different from zooming.