GNU bug report logs - #19972
24.4; Font size change doesn't update (window-total-width)

Previous Next

Full log

Message #170 received at 19972 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, "Jan D." <jan.h.d <at> swipnet.se>
Cc: steve <at> sanityinc.com, 19972 <at> debbugs.gnu.org
Subject: Re: bug#19972: Font size change doesn't update (window-total-width)
Date: Tue, 03 Mar 2015 18:47:21 +0100

> But I don't see anything like that on MS-Windows: we do have a call to
> change_frame_size when we receive a WM_SIZE message, but running the
> recipe in this thread doesn't cause WM_SIZE to be received,

There should be one for a normally sized frame.

> and the
> call to change_frame_size, if it is done, comes via
> internal-set-lisp-face-attribute and modify-frame-parameters,
> i.e. directly from Lisp.  (When the frame is maximized,
> change_frame_size is not called at all.

Neither on X, hopefully ;-)

> )
>
> Martin, can you tell what is the equivalent of the above X processing
> on MS-Windows?  Does Emacs implement a similar logic internally?

I'm not sure I understand what you mean.  Basically, on Windows we
process the sizes immediately when issuing a size request.  "Process" in
this context means to store the sizes in the frame structure and resize
the frame's windows accordingly.

We do that in the change_frame_size call on line 6173 of w32term.c
(because Drew wanted to see the possible future effect immediately in
the frame sizes).  When Windows gets back to us via a WM_SIZE message we
might eventually call change_frame_size too (on line 5180 of w32term.c)
but do so only if the requested sizes differ from the already stored
ones.  The sizes usually differ when the request was initiated by
Windows (like when the user clicks at the maximize button or mouse-drags
a frame edge) and usually do not differ when the request was initiated
by Lisp code before.

On X we don't process the sizes immediately but rather loop until we get
a notifcation event (similar to WM_SIZE) or a timeout expires.  In the
latter case the frame would have remained unchanged while on Windows it
would have changed (due to the call of line 6173).  So far I have not
seen any inconsistencies on Windows.  These would appear as decorations
that are either too large or too small for our frame.  In any case, a
refusal to resize our window without any notification (like seen by the
OP of the current thread on NS) would obviously hit us on Windows.

When I asked you back then whether we could implement something similar
to the X code on Windows you told me that Windows doesn't have anything
comparable to ConfigureNotify so I didn't pursue the idea any further.
If and when problems pop up with the current code we might have to
reconsider that.

martin

Previous Next

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