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

[martin rudalics <rudalics@gmx.at>]

 > I think we're talking about this behavior:
 >
 >  Also, if FRAME is non-nil, alter the user's Customization
 >  settings as though the font-related attributes of the
 >  `default' face had been \"set in this session\", so that
 >  the font is applied to future frames.
 >
 > 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.

 > 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 haven't touched my font
related Emacs settings for ages - the effect was that I usually ended up
with a completely messed up frame.  Do you see a changed default face at
least when you call that function?

 >> I did so and still think it's the correct answer in an
 >> environment that has to cater for fullscreen and maximized
 >> frames as well as for tiling window managers.  I don't think
 >> that zooming the font size in any of these modes should
 >> change the frame size.
 >
 > Use `set-frame-font' with non-nil KEEP-SIZE if you do not want the frame to zoom
 > along with its text and you want to change how much text is visible in the same
 > frame.  That's what KEEP-SIZE is for.

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

 > 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.  The
scrollbar currently doesn't - but it has larger increments IIRC.

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

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

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

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

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

martin