GNU bug report logs - #14233
24.3; Don't constrain frame size to character multiples

Previous Next

Package: emacs;

Reported by: E Sabof <esabof <at> gmail.com>

Date: Sat, 20 Apr 2013 00:04:02 UTC

Severity: wishlist

Found in version 24.3

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 'Eli Zaretskii' <eliz <at> gnu.org>, esabof <at> gmail.com, 14233 <at> debbugs.gnu.org
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)
			      (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




This bug report was last modified 10 years and 154 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.