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

Previous Next

Full log

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: steve <at> sanityinc.com, jan.h.d <at> swipnet.se, 19972 <at> debbugs.gnu.org
Subject: Re: bug#19972: Font size change doesn't update (window-total-width)
Date: Thu, 05 Mar 2015 19:14:39 +0100

>>   > I don't see why do we have to block and wait.  Why not simply go about
>>   > our business, and let the WM_SIZE message come in when it does, and be
>>   > handled?
>>
>> Because of Bug#16028 :-(
>
> Which part of that bug disallows the above?

Well, before the "fix" of bug#16028 Emacs behaved as you described
above.

Suppose an application wants to add 5 lines and 5 columns to a frame.
It can do that in one call

(set-frame-size nil (+ (frame-width) 5) (+ (frame-height) 5))

or via

(progn
  (set-frame-width nil (+ (frame-width) 5))
  (set-frame-height nil (+ (frame-height) 5)))

I suppose that most people would consider these forms idempotent.

However, before the fix, `set-frame-height' could fail because Emacs has
to tell Windows (via AdjustWindowRect) what the desired window width is.
But the width Emacs knows about at that time is still that from before
the `set-frame-width' call.

On X this scenario doesn't fail because Emacs usually loops long enough
until the width value has been updated.  I don't know how NS handles it.

Similar scenarios can be devised when changing any of the values
affected by `frame-inhibit-implied-resize'.

martin

Previous Next

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