bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#14326: 24.3; Conflict of w32-send-sys-command and set-default-font


From: Eli Zaretskii
Subject: bug#14326: 24.3; Conflict of w32-send-sys-command and set-default-font
Date: Thu, 02 May 2013 21:55:12 +0300

> Date: Thu, 02 May 2013 20:32:54 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 
>  >> Do you mean that `set-default-font' does not cause a WM_SIZE message?
>  >
>  > It does (although not with a maximize request), but that's not what I
>  > meant.  I meant that set-default-font immediately causes the internals
>  > to reflect the change, whereas for w32-send-sys-command this only
>  > happens _after_ Emacs receives the maximize request and acts upon it
>  > by resizing the frame.
> 
> w32term.c contains the following comment text:
> 
>    /* The following mirrors what is done in xterm.c. It appears to be
>       for informing lisp of the new size immediately, while the actual
>       resize will happen asynchronously. But on Windows, the menu bar
>       automatically wraps when the frame is too narrow to contain it,
>       and that causes any calculations made here to come out wrong. The
>       end is some nasty buggy behavior, including the potential loss
>       of the minibuffer.
> 
>       ...  */

The code thus commented is ifdef'ed away...

> So we reflect the change internally for `set-default-font', which, when
> changing the default font to a very small size may easily cause a wrap
> of the menubar, while we do not reflect the change internally for a
> maximization which hardly ever will cause the menubar to wrap more than
> it wrapped before.

That's not the issue here.  The issue here is that, when
w32-send-sys-command is used, Emacs doesn't have any way of knowing
that this call is going to change the frame's size.  The argument to
w32-send-sys-command is just some mumbo-jumbo as far as Emacs is
concerned.  Only when the WM_SIZE message comes in as result of that,
do we know that the frame size is about to change.

By contrast, set-default-font works in the opposite direction: Emacs
_does_ understand what that means, it does know how to load a font and
get its metrics, and it does know how to resize the frame as result.
So even if the actual resize involves some messages that need to come
to our window procedure, that doesn't matter, because we are already
ready for the resize.  Not so when w32-send-sys-command is used.

Or at least this is my understanding, admittedly very limited in this
area.

Btw, try "M-: (set-default-font "David-8") RET" in "emacs -Q", and you
will see that the tool bar (not the menu bar) will wrap, but I see no
adverse effects of that.  So I really don't see why we should be
afraid of such wrapping.





reply via email to

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