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

[Drew Adams]

>  > Try going smaller rather than larger.
> 
> Then I won't see anything any more.

You can still type into the frame, even when you can no longer read its text.
And you can have a larger copy of the same buffer in another frame, for
reference.  Not important; just mentioning it.

>  >>  > 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?
> 
> I thought "future behavior" referred to the future behavior 
> of Emacs in this regard.  And I would like to change that
> indeed.

Dunno what you mean by that, as opposed to what you say next:

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

> Whether "setting the default font" via the menu should affect 
> one frame, all existing frames, or future frames is an issue
> that should be discussed separately.

Whether by menu or otherwise, setting face `default', which includes the default
font (though I'm not sure there is such a critter, explicitly), is different
from setting the `font' parameter for a specific frame.  

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.

This is the problem (one of them) that we have been discussing: whether future
frames should be affected when you change `font' for one frame (whether by
`modify-frame-parameters' or `set-frame-font').

I'm glad to hear that you agree that they should not be affected.

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

Great.

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

Good again.

>  > 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?
> 
> Because it incredibly complicates the implementation of setting a
> font on a specific frame.  With emacs 24.3 we conceptually
> 
> (1) set the font which changes the appearance of text within the frame
>      and the number of pixels used for the display margins,
> 
> (2) set the frame size proportionally to the font and rounded 
>      which may cause resizing the frame,
> 
> (3) set the sizes of fringes proportionally to the font and rounded
>      which may cause another resizing of the frame, and
> 
> (4) set the sizes of the scrollbars proportionally to the font and
>      rounded which may cause yet another resizing of the frame.
> 
> Now I think that all these steps are really useful to get a 
> nice frame, after all, a large font does look bad with narrow 
> scrollbars and tiny fringes.  But the problem is that these
> steps must be implemented via recursive calls to
> `modify-frame-parameters'.  And these cause conflicts, for
> example, when a user also issues a request to set the
> size of the frame in the same `modify-frame-parameters' call that
> changes the font or a request to maximize the frame.

Yes, I can understand that.

> So I think that a separate function should be provided to do 
> such frame zooming in a pretty and obviously pixelwise
> fashion where a user should be also allowed to specify
> things like a sizing factor (which allows to
> resize the frame more/less agressively wrt the font change)
> and some upper and lower bounds which guarantee for example
> that the frame never exceeds the size of the screen and/or
> obscurs the taskbar and a separate options which allows to
> zoom only text or images as well.

The devil will be in the details.  I don't disagree with what you say in the
abstract.  As long as users (including via Lisp) have equal or more control than
now, and the use is not overly complex, I'll probably be OK with whatever you
come up with.  I do recognize the complications you describe, whether only
potential or real (in practice).

>  >> 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.
> 
> My concerns are implementation concerns only.  We're asking too much
> from that function `modify-frame-parameters'

OK, your arguments about that make sense.  But keep in mind that it has been
around a long time and worked well in general.  Whatever it is replace with
should do at least what it does.

And keep in mind that, regardless of potential problems that you underline, it
has been useful as a general workhorse function, and it is easy to use.

I would particularly not wish to see it replaced only by some incredibly complex
thing, a la what what done wrt buffer display.  Exact, logical, and precise is
good.  But simple use is good too.  Cleanup is good, but let's not throw out the
baby with the bathwater.

>  > 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.
> 
> Which is useless IMO.

No, not really.  Whether Emacs or another application, users sometimes do
intentionally move window-mgr windows partly off screen, for various reasons.
The window mgr does the clipping to truncate the off-screen parts - the
application need not bother with that.

But this is generally beside the main points being discussed.

>  > 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 now think we need a more intelligent function than `set-frame-font'
> much like the one I sketched above.

Please try to also keep a simple-use function (some function), in addition to
providing for cleaner, more exact definition/control.

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

>  > 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).
> 
> A user must be able to choose between text-based zooming and
> text+image-based zooming.  But I have no idea how image positions
> correlate to text positions so I don't know how zooming affects the
> relative positions of text mixed with images.

I don't know either.  These are things to keep in mind, and perhaps dealt with
later.  Hopefully someone will know or learn more and be able to offer insight.

>  >> Are you sure?  What if toolbars have accompanying text?
>  >
>  > I meant the toolbar images.
> 
> Some toolbars can have accompanying text and that text is 
> AFAICT subject to frame font changes.
> 
>  >>  > 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.
> 
> So the font changing code has to handle that.

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

>  > 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'.
> 
> Which as you said should be probably fixed.  But I still find 
> it better to rewrite such a function from scratch.