unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>, "Jan D." <jan.h.d@swipnet.se>
Cc: steve@sanityinc.com, 19972@debbugs.gnu.org
Subject: bug#19972: Font size change doesn't update (window-total-width)
Date: Tue, 03 Mar 2015 18:47:21 +0100	[thread overview]
Message-ID: <54F5F3A9.1090108@gmx.at> (raw)
In-Reply-To: <837fuyqcx5.fsf@gnu.org>

 > 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





  reply	other threads:[~2015-03-03 17:47 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-01  2:31 bug#19972: 24.4; Font size change doesn't update (window-total-width) Joost Kremers
2015-03-01 15:14 ` martin rudalics
2015-03-01 15:28   ` Eli Zaretskii
2015-03-01 15:54     ` martin rudalics
2015-03-01 17:07     ` Joost Kremers
2015-03-01 17:46       ` Eli Zaretskii
2015-03-01 20:43         ` Joost Kremers
2015-03-02  3:30           ` Eli Zaretskii
2015-03-02  3:59             ` Joost Kremers
2015-03-02 14:04               ` Eli Zaretskii
2015-03-02 17:08                 ` martin rudalics
2015-03-02 17:35                   ` Eli Zaretskii
2015-03-02 18:12                     ` martin rudalics
2015-03-02 18:25                       ` Eli Zaretskii
2015-03-02 18:43                         ` martin rudalics
2015-03-02 18:46                           ` Eli Zaretskii
2015-03-02 22:26                 ` Joost Kremers
2015-03-03  3:36                   ` Eli Zaretskii
2015-03-03  8:07                     ` martin rudalics
2015-03-03  9:06                       ` Jan Djärv
2015-03-03 10:17                         ` martin rudalics
2015-03-03 11:05                           ` Jan D.
2015-03-03 11:26                             ` martin rudalics
2015-03-03 12:08                               ` Jan D.
2015-03-03 12:08                     ` Joost Kremers
2015-03-03  8:06                   ` martin rudalics
2015-03-02 17:08           ` martin rudalics
2015-03-02 17:07         ` martin rudalics
2015-03-02 17:06       ` martin rudalics
2015-03-01 17:06   ` Joost Kremers
2015-03-02  3:18   ` Joost Kremers
2015-03-02 17:09     ` martin rudalics
2015-03-02 17:24       ` Eli Zaretskii
2015-03-02 18:12         ` martin rudalics
2015-03-02 18:26           ` Eli Zaretskii
2015-03-03 10:38       ` martin rudalics
2015-03-03 12:23         ` Joost Kremers
2015-03-04 15:10           ` martin rudalics
2017-10-02  8:48             ` martin rudalics
2015-03-02  7:57 ` bug#19972: " Steve Purcell
2015-03-02 13:27   ` Eli Zaretskii
2015-03-02 14:07     ` Steve Purcell
2015-03-02 14:09       ` Steve Purcell
2015-03-02 14:24         ` Eli Zaretskii
2015-03-02 17:37         ` Jan D.
2015-03-02 14:23       ` Eli Zaretskii
2015-03-02 17:42     ` Jan D.
2015-03-02 17:56       ` Eli Zaretskii
2015-03-02 19:06         ` Jan D.
2015-03-02 19:52           ` Eli Zaretskii
2015-03-02 20:19             ` Jan D.
2015-03-03 16:11               ` Eli Zaretskii
2015-03-03 17:47                 ` martin rudalics [this message]
2015-03-03 18:02                   ` Eli Zaretskii
2015-03-03 18:36                     ` martin rudalics
2015-03-03 18:38                       ` Eli Zaretskii
2015-03-04 15:10                         ` martin rudalics
2015-03-04 17:47                           ` Eli Zaretskii
2015-03-04 18:45                             ` martin rudalics
2015-03-04 18:59                               ` Eli Zaretskii
2015-03-04 19:25                                 ` Jan D.
2015-03-05  8:06                                 ` martin rudalics
2015-03-05 16:34                                   ` Eli Zaretskii
2015-03-05 18:14                                     ` martin rudalics
2015-03-05 20:22                                       ` Eli Zaretskii
2015-03-05 21:15                                         ` martin rudalics
2015-03-06  8:09                                           ` Eli Zaretskii
2015-03-06  9:21                                             ` martin rudalics
2015-03-06 10:58                                               ` Eli Zaretskii
2015-03-02 14:44   ` Drew Adams
2015-03-02 15:02     ` Steve Purcell
2015-03-02 17:10   ` martin rudalics
2015-03-02 17:23     ` Steve Purcell
2015-03-02 18:12       ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54F5F3A9.1090108@gmx.at \
    --to=rudalics@gmx.at \
    --cc=19972@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=jan.h.d@swipnet.se \
    --cc=steve@sanityinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).