[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: martin rudalics
Subject: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Tue, 30 Apr 2013 09:34:56 +0200

> 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)
                             (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 
> along with its text and you want to change how much text is visible in the 
> 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 
> 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 
> 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 
> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]