From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#14326: 24.3; Conflict of w32-send-sys-command and set-default-font Date: Fri, 03 May 2013 08:48:27 +0200 Message-ID: <51835DBB.1060609@gmx.at> References: <5180DD2B.3080407@gmx.at> <83a9oepwuu.fsf@gnu.org> <5182307C.6000102@gmx.at> <83mwsdnwc8.fsf@gnu.org> <5182B156.2000100@gmx.at> <83bo8tnre7.fsf@gnu.org> <5182B999.4050304@gmx.at> <838v3xnpdo.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1367563771 18800 80.91.229.3 (3 May 2013 06:49:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 May 2013 06:49:31 +0000 (UTC) Cc: eenliu@gmail.com, 14326@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 03 08:49:31 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UY9oA-0006QB-Se for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 May 2013 08:49:31 +0200 Original-Received: from localhost ([::1]:43558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UY9oA-0007uX-IW for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 May 2013 02:49:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UY9o6-0007uH-Ro for bug-gnu-emacs@gnu.org; Fri, 03 May 2013 02:49:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UY9o5-0007xd-QG for bug-gnu-emacs@gnu.org; Fri, 03 May 2013 02:49:26 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52175) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UY9o5-0007xW-NM for bug-gnu-emacs@gnu.org; Fri, 03 May 2013 02:49:25 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UY9oh-0005vz-3P for bug-gnu-emacs@gnu.org; Fri, 03 May 2013 02:50:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 May 2013 06:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14326 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: Original-Received: via spool by 14326-submit@debbugs.gnu.org id=B14326.136756375722639 (code B ref 14326); Fri, 03 May 2013 06:50:03 +0000 Original-Received: (at 14326) by debbugs.gnu.org; 3 May 2013 06:49:17 +0000 Original-Received: from localhost ([127.0.0.1]:56282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UY9nx-0005t2-69 for submit@debbugs.gnu.org; Fri, 03 May 2013 02:49:17 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:50588) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UY9nr-0005sM-Av for 14326@debbugs.gnu.org; Fri, 03 May 2013 02:49:13 -0400 Original-Received: from mailout-de.gmx.net ([10.1.76.29]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LqGSs-1U3Tjj2ZXM-00dkBj for <14326@debbugs.gnu.org>; Fri, 03 May 2013 08:48:31 +0200 Original-Received: (qmail invoked by alias); 03 May 2013 06:48:31 -0000 Original-Received: from 62-47-53-246.adsl.highway.telekom.at (EHLO [62.47.53.246]) [62.47.53.246] by mail.gmx.net (mp029) with SMTP; 03 May 2013 08:48:31 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX18AAJhD6rMACLRJLt0lIk3dvRxDGVP45ys+vn4Dw8 dJrZQHsYKlgDDj In-Reply-To: <838v3xnpdo.fsf@gnu.org> X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:73907 Archived-At: >> That's what I'm wondering about. > > You cannot just call change_frame_size on Windows anyway. It doesn't > do what you'd expect. I see no difference. On Windows I call it when the window manager gets back to me with the final frame size. On X I call it after sending the request to the window manager and a second time after the window manager gets back to me (where the second call usually returns at "If we're not changing the frame size, quit now.") The first call on X makes no sense as the event sequence on Windows demonstrates. >> So w32-send-sys-command is handled differently from setting the >> fullscreen frame parameter to maximized? > > Not really: the latter is implemented by calling the former (or > actually doing the same independently). > >> Does this mean the OP could have used `set-frame-parameter' and it >> would have worked in his sense? > > No, see above. That's what I thought. Hopefully `set-default-font`' at least resets the maximized frame parameter. In any case I'd consider it a bug that `set-default-font' is allowed to resize a maximized frame. >> > 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. >> >> But when x_set_window_size tells Windows that it wants to resize the >> frame, it stumbles into some away-defined code. > > Not sure what x_set_window_size has to do with all this. That's the routine we're talking about here (the one with the comment about menubar wrapping, the one containing the ifdef'ed code, and the one talking to the window manager via my_set_window_pos). >> We do our own toolbar wrapping. But the menubar is wrapped by Windows. > > And that is a problem because...? ... two. Two problems. Glad you asked. When I fit the size of a frame to that of its buffer, I ideally would do this in one `modify-frame-parameters' call to set the size of the new frame. But if this call shrinks the frame, both the menubar and the toolbar may wrap and my calculations get ignored. To avoid that I shall have to proceed as below. For the menubar the appropriate steps are: (1) I calculate the new frame size and post a request to change the frame width. (2) The window manager may decide that for the new frame width it has to wrap the menubar and does so by shrinking the height of my client rectangle and telling me the new sizes. (3) I post a second request to set the new frame height. This means that to handle the possibility that the menubar may wrap, I have to post two separate resize requests to the window manager instead of one. For the toolbar the appropriate steps are: (1) I calculate the new frame size and post a request to change the frame width. (2) Emacs decides that for the new frame width it has to wrap the toolbar and does so by shrinking the height of my root window. (3) I post a second request to set the new frame height. This means that to handle the possibility that the toolbar may wrap I have to split the resize request into two separate steps. I don't have to contact the window manager for the toolbar resizing case but since I might have to do it for the menubar case anway I don't care. Obviously, this means that I send a second request to the window manager also when only the toolbar wraps. martin