Truly maximize w32 frames with odd fonts and some texi fixes.

* w32fns.c (w32_wnd_proc): For WM_WINDOWPOSCHANGING don't
constrain frame size in SW_SHOWMAXIMIZED case so we can truly
maximize a frame for odd default fonts.
* frames.texi (Size and Position): In `frame-resize-pixelwise'
description drop remark about frame maximization.
* windows.texi (Display Action Functions): Add description for
`display-buffer-no-window' and explain use of `allow-no-window'
alist entries.

3 files changed, 14 insertions, 19 deletions

diff --git a/src/ChangeLog b/src/ChangeLog
index d2572e74048..ccd8fb46957 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,9 @@
+2014-03-21  Martin Rudalics  <rudalics@gmx.at>
+
+        * w32fns.c (w32_wnd_proc): For WM_WINDOWPOSCHANGING don't
+        constrain frame size in SW_SHOWMAXIMIZED case so we can truly
+        maximize a frame for odd default fonts.
+
 2014-03-20  Paul Eggert  <eggert@cs.ucla.edu>
 
         * doc.c (store_function_docstring): Fix pointer signedness mismatch.
diff --git a/src/w32fns.c b/src/w32fns.c
index a5b8abfa6b1..ffe63a3cf2d 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -3805,7 +3805,8 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
         wp.length = sizeof (WINDOWPLACEMENT);
         GetWindowPlacement (hwnd, &wp);
 
-        if (wp.showCmd != SW_SHOWMINIMIZED && (lppos->flags & SWP_NOSIZE) == 0)
+        if (wp.showCmd != SW_SHOWMAXIMIZED && wp.showCmd != SW_SHOWMINIMIZED
+            && (lppos->flags & SWP_NOSIZE) == 0)
           {
             RECT rect;
             int wdiff;
diff --git a/src/w32term.c b/src/w32term.c
index 2981320e136..ac8f9a2092d 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -5651,21 +5651,11 @@ x_set_window_size (struct frame *f, int change_gravity, int width, int height, b
   if (!frame_resize_pixelwise)
     {
       /* If we don't resize frames pixelwise, round sizes to multiples
-         of character sizes.  Otherwise, Windows may clip our frame
-         rectangle at a character size boundary and we risk losing our
-         mode line.  Bug#16923 might be a consequence of this.
-
-         So far, this is a Windows specific problem; other toolkits may
-         prefer to not resize the frame if the delta is not large enough
-         (GTK) or resize the frame pixelwise as requested (Lucid,
-         Motif).  Windows just doesn't call us back (probably because of
-         the size hint settings which it apparently interprets strictly)
-         neither when the user tries to mouse-drag a frame border by,
-         nor when calling `set-frame-size' with a delta of less than the
-         canonical character size.  If w32_enable_frame_resize_hack is
-         enabled (which it now is by default) we'd then below resize the
-         frame's root window in preparation of a WM_SIZE message to come
-         which, however, is not going to happen. */
+         of character sizes here.  Otherwise, when enforcing size hints
+         while processing WM_WINDOWPOSCHANGING in w32_wnd_proc, we might
+         clip our frame rectangle to a multiple of the frame's character
+         size and subsequently lose our mode line or scroll bar.
+         Bug#16923 could be one possible consequence of this.  */
       int unit_width = FRAME_COLUMN_WIDTH (f);
       int unit_height = FRAME_LINE_HEIGHT (f);
 
@@ -5695,9 +5685,7 @@ x_set_window_size (struct frame *f, int change_gravity, int width, int height, b
   }
 
   /* If w32_enable_frame_resize_hack is non-nil, immediately apply the
-     new pixel sizes to the frame and its subwindows.  This approach is
-     fragile because Windows might not honor the resize request issued
-     by my_set_window_pos with a WM_SIZE message (see previous comment).
+     new pixel sizes to the frame and its subwindows.
 
      Jason Rumney earlier refused to call change_frame_size right here
      with the following argument: