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

[Drew Adams]

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

My bad.  The disjointedness of our edited emails made me think somehow that this
was about KEEP-SIZE, not FRAMES.  IOW, I lost the thought thread.

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

My bad again.  In the recipe I gave, I used what I intended as the FRAMES arg as
the KEEP-SIZE arg, and so I actually omitted the FRAMES arg.

So I take back what I said about it not doing what is documented.
Sorry for that noise.

>  >> 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 see; good test.  I was only judging by appearance, and I was judging poorly.
Looking closer now, I can see that the fringe does change size.

But it does not change proportionately wrt the font change.

With font size 25 I see fringe of width 15 (ratio: 1.667)
               13                        8 (ratio: 1.625)
                9                       10 (ratio: 1.111)

And the last two lines really make one wonder.  Anyway, you are correct that the
fringe does get resized.  But zooming the font does not zoom the fringe
similarly.

Anyway, let's not won't worry too much about the fringe behavior, for now. 

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

Large sizes of the font?  I just tried up to size 200 (chars several cm high),
and the scroll bar stayed (visibly) the same.  (I didn't check the parameter
values.)

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

Try going smaller rather than larger.

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

Why should it?  Why should modifying one frame affect all future frames?  That
makes no sense to me.  If you make one frame background light blue, do you
expect all future frames to also have a light blue background?  If so, why?

Much as I could be persuaded wrt whether `modify-frame-parameters' should zoom
the frame size when you zoom the `font' parameter, I do not see any
justification for `modify-frame-parameters' affecting other than the targeted
frame.  That just sounds perverse to me, and I expect it would lead to all kinds
of unwelcome 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.
> 
> I'd prefer the frame + external objects to keep the same 
> number of pixels.

As I said, the choice should be up to the user.  Different users will have
different use cases (and preferences), and the same user will have different use
cases at different times.

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

Why is it necessary for `modify-frame-parameters' to behave like
`set-frame-size' with a non-nil (thus non-default) KEEP-SIZE argument, and wrong
for `modify-frame-parameters' to behave like `set-frame-size' with a nil (thus
default) KEEP-SIZE argument?

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

I cannot speak to the implementation concerns.  I'm speaking in user terms.

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

Well stated.  We just disagree, I guess.

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

By definition, a maximized frame is outside the notion of zooming a frame, that
is, where zooming includes changing the frame size.  So it is irrelevant to what
I'm talking about.

For the kind of zooming I'm talking about, either zooming larger would no longer
be available once the maximum size is reached or it would be available beyond
the "maximum", which is really just the screen size.  The latter is the case
today, BTW: you can zoom a frame larger than the screen.

> In any case, my concern is to make frame parameter handling
> via `modify-frame-parameters' predictable, in some sense at least.

I think we agree on that.

> Currently, I'm completely lost in a jungle of things that get
> processed in some incomprehensible fashion.

You are no doubt trying to understand a much bigger picture than I'm looking at,
and that is needed here, I recognize.  I would submit that for the use case I'm
talking about, zooming a frame (its size and its font size), things are pretty
straightforward from a user perspective and in terms of appearances.

Yes, I'm not too concerned with other parameters besides `font' wrt this use
case.  I don't really care much what the sizes of fringe and scroll bars are.
Not that they are not important, but they are not very important to my use case.

In the end, you will probably do what you're suggesting, and I will probably end
up using `set-frame-font' instead of `modify-frame-parameters' to continue to
get the effect I want.  (For Emacs 20 & 21 there was no KEEP-SIZE parameter, so
I'll need to use `modify-frame-parameters' for those cases.)

I guess I'm saying that, provided that there is some sensitivity to continuing
to make the behavior I currently take advantage of available, in some way (e.g.
`set-frame-font'), I would probably be OK with your changing
`modify-frame-parameters' along the lines you suggest.

At least I have confidence that you will remain open to reported problems and
you will no doubt DTRT.

As I hinted earlier, I would like, eventually, to see the same kind of
`KEEP-SIZE' behavior available for zooming other things, besides `font'.

For example, when zooming a frame (which for me, again, means shrinking both its
content and its size), if it contains images then I would want to be able to
shrink the images as well (modulo losing resolution, of course), in such a way
that what appears in the frame remains essentially the same (unlike the case of
a web browser, for example).

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

I meant the toolbar images.

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

For me, on MS Windows, changing option `tool-bar-style' to include text has no
effect: I never see any text, just images.  And the doc string says this:

  This variable only affects the GTK+ toolkit version of Emacs.

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

OK.  But my concern is that we not lose something that users have today.  Wrt
font zooming also zooming frame size, I guess we won't lose, since we can use
`set-frame-font' with nil `KEEP-SIZE'.

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

Thanks for your discussion and consideration of my use case.  I have confidence
that in the end things will work out well, since you are working on this.
Seriously.