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

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

[Eric Liu]

[-- Attachment #1: Type: text/plain, Size: 2944 bytes --]

I am running Emacs 24.3 on Windows 7, with only two commands in my Emacs
init file:
    (w32-send-sys-command 61488) ;; maximize frame at startup
    (set-default-font "Monaco-10")
The first command works well alone, but it stops to maximize frame after
the second one is
added to init file. However, if eval them after Emacs starts up by M-x
eval-expression, then  (w32-send-sys-command 61488) still works.

Discussion on gnu.emacs.help:
    https://groups.google.com/forum/#!topic/gnu.emacs.help/qJRp0XEf2U0



In GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
 of 2013-03-17 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <menu-bar> <help-menu> <send-emacs-bug
-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win
w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32 multi-tty emacs)

[-- Attachment #2: Type: text/html, Size: 3455 bytes --]

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

[martin rudalics]

 > I am running Emacs 24.3 on Windows 7, with only two commands in my Emacs
 > init file:
 >     (w32-send-sys-command 61488) ;; maximize frame at startup
 >     (set-default-font "Monaco-10")
 > The first command works well alone, but it stops to maximize frame after
 > the second one is
 > added to init file. However, if eval them after Emacs starts up by M-x
 > eval-expression, then  (w32-send-sys-command 61488) still works.

Does interchanging the order of these two lines change anything?  What
happens when, with emacs -Q, you evaluate the form

(progn
   (w32-send-sys-command 61488) ;; maximize frame at startup
   (set-default-font "Monaco-10"))

and what happens when you do

(progn
   (w32-send-sys-command 61488) ;; maximize frame at startup
   (sit-for 1)
   (set-default-font "Monaco-10"))

instead?

Conceptually: Does anyone know whether sending a 61488 request to
Windows has Windows call us back with a maximize request?

martin

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

[Eli Zaretskii]

> Date: Wed, 01 May 2013 11:15:23 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 14326@debbugs.gnu.org
> 
>  > I am running Emacs 24.3 on Windows 7, with only two commands in my Emacs
>  > init file:
>  >     (w32-send-sys-command 61488) ;; maximize frame at startup
>  >     (set-default-font "Monaco-10")
>  > The first command works well alone, but it stops to maximize frame after
>  > the second one is
>  > added to init file. However, if eval them after Emacs starts up by M-x
>  > eval-expression, then  (w32-send-sys-command 61488) still works.
> 
> Does interchanging the order of these two lines change anything?

I'd be surprised if it didn't.  It does here.  See below.

> and what happens when you do
> 
> (progn
>    (w32-send-sys-command 61488) ;; maximize frame at startup
>    (sit-for 1)
>    (set-default-font "Monaco-10"))
> 
> instead?

Doesn't work, either.  Triggering redisplay doesn't help here.

> Conceptually: Does anyone know whether sending a 61488 request to
> Windows has Windows call us back with a maximize request?

Of course, it does.  (And the 61488 request is not sent to Windows, it
is sent to our own window procedure.)  Since we don't process the
61488 (a.k.a. WM_SYSCOMMAND) message, we get WM_SIZE as its result.
Until we get that WM_SIZE message, our frame is not really maximized,
and its dimensions are not reflected in the frame object's internals.
So set-default-font uses the previous dimensions, and effectively
resets or countermands the effect of w32-send-sys-command.

Invoking the commands in the reverse order doesn't have this problem,
because the effect of set-default-font is immediate.

Moreover, I submit that the OP does not _want_ to invoke
set-default-font after maximizing the frame, even if it did work.
That's because changing the font of a maximized frame will either make
it not maximized (if the new font is smaller) or make some of its
parts, such as the minibuffer, invisible (if the font is larger).  The
machinery that maximizes the frame takes the font into account, so
changing the font afterwards defeats what it does by invalidating all
the pixel calculations Windows does using the previous font.

IOW, this is not a bug, but rather a cockpit error.  The correct way
is to swap the order of these two lines.

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

[Eric Liu]

[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]

Yes, swapping the two lines does work. Thank you guys!


On Wed, May 1, 2013 at 8:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Wed, 01 May 2013 11:15:23 +0200
> > From: martin rudalics <rudalics@gmx.at>
> > Cc: 14326@debbugs.gnu.org
> >
> >  > I am running Emacs 24.3 on Windows 7, with only two commands in my
> Emacs
> >  > init file:
> >  >     (w32-send-sys-command 61488) ;; maximize frame at startup
> >  >     (set-default-font "Monaco-10")
> >  > The first command works well alone, but it stops to maximize frame
> after
> >  > the second one is
> >  > added to init file. However, if eval them after Emacs starts up by M-x
> >  > eval-expression, then  (w32-send-sys-command 61488) still works.
> >
> > Does interchanging the order of these two lines change anything?
>
> I'd be surprised if it didn't.  It does here.  See below.
>
> > and what happens when you do
> >
> > (progn
> >    (w32-send-sys-command 61488) ;; maximize frame at startup
> >    (sit-for 1)
> >    (set-default-font "Monaco-10"))
> >
> > instead?
>
> Doesn't work, either.  Triggering redisplay doesn't help here.
>
> > Conceptually: Does anyone know whether sending a 61488 request to
> > Windows has Windows call us back with a maximize request?
>
> Of course, it does.  (And the 61488 request is not sent to Windows, it
> is sent to our own window procedure.)  Since we don't process the
> 61488 (a.k.a. WM_SYSCOMMAND) message, we get WM_SIZE as its result.
> Until we get that WM_SIZE message, our frame is not really maximized,
> and its dimensions are not reflected in the frame object's internals.
> So set-default-font uses the previous dimensions, and effectively
> resets or countermands the effect of w32-send-sys-command.
>
> Invoking the commands in the reverse order doesn't have this problem,
> because the effect of set-default-font is immediate.
>
> Moreover, I submit that the OP does not _want_ to invoke
> set-default-font after maximizing the frame, even if it did work.
> That's because changing the font of a maximized frame will either make
> it not maximized (if the new font is smaller) or make some of its
> parts, such as the minibuffer, invisible (if the font is larger).  The
> machinery that maximizes the frame takes the font into account, so
> changing the font afterwards defeats what it does by invalidating all
> the pixel calculations Windows does using the previous font.
>
> IOW, this is not a bug, but rather a cockpit error.  The correct way
> is to swap the order of these two lines.
>

[-- Attachment #2: Type: text/html, Size: 3303 bytes --]

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

[Eli Zaretskii]

> Date: Wed, 1 May 2013 10:33:19 -0700
> From: Eric Liu <eenliu@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>, 14326@debbugs.gnu.org
> 
> Yes, swapping the two lines does work. Thank you guys!

Thanks, I'm closing the bug.

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

[martin rudalics]

 > Invoking the commands in the reverse order doesn't have this problem,
 > because the effect of set-default-font is immediate.

Do you mean that `set-default-font' does not cause a WM_SIZE message?

martin

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

[Eli Zaretskii]

> Date: Thu, 02 May 2013 11:23:08 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: eenliu@gmail.com, 14326@debbugs.gnu.org
> 
>  > Invoking the commands in the reverse order doesn't have this problem,
>  > because the effect of set-default-font is immediate.
> 
> 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.

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

[martin rudalics]

 >> 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.

      ...  */

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.

Something doesn't make sense here :-(

martin

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

[Eli Zaretskii]

> Date: Thu, 02 May 2013 20:32:54 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: eenliu@gmail.com, 14326@debbugs.gnu.org
> 
>  >> 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.

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

[martin rudalics]

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

That's what I'm wondering about.

 > 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.

So w32-send-sys-command is handled differently from setting the
fullscreen frame parameter to maximized?  Does this mean the OP could
have used `set-frame-parameter' and it would have worked in his sense?

 > 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.

 > 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.

We do our own toolbar wrapping.  But the menubar is wrapped by Windows.

martin

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

[Eli Zaretskii]

> Date: Thu, 02 May 2013 21:08:09 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: eenliu@gmail.com, 14326@debbugs.gnu.org
> 
>  > The code thus commented is ifdef'ed away...
> 
> 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.

>  > 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.
> 
> 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.

>  > 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.

>  > 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.
> 
> We do our own toolbar wrapping.  But the menubar is wrapped by Windows.

And that is a problem because...?

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

[martin rudalics]

 >> 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

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

[Eli Zaretskii]

> Date: Fri, 03 May 2013 08:48:27 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: eenliu@gmail.com, 14326@debbugs.gnu.org
> 
>  >> 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.

I was trying to explain why that comment might be of only historical
interest, since it describes code that we don't use.

>  >> 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.

I don't think it does.  And I'm not sure it should.

>  In any case I'd consider it a bug that `set-default-font' is
> allowed to resize a maximized frame.

That's what your changes are about, I think.

>  >>  > 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

I understand, but I don't see how it is related to set-default-font.

> 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.

Do we really want to allow resizing that causes this wrap, when what
the user wants is to fit frame size to buffer?

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

[martin rudalics]

 > I was trying to explain why that comment might be of only historical
 > interest, since it describes code that we don't use.

The code is used on X.

 >> That's what I thought.  Hopefully `set-default-font`' at least resets
 >> the maximized frame parameter.
 >
 > I don't think it does.  And I'm not sure it should.

You mean that `frame-parameters' should be allowed to report a frame as
maximized even after it was explicitly demaximized?

 >>  > Not sure what x_set_window_size has to do with all this.
 >>
 >> That's the routine we're talking about here
 >
 > I understand, but I don't see how it is related to set-default-font.

It may eventually get called by it.

 >> 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.
 >
 > Do we really want to allow resizing that causes this wrap, when what
 > the user wants is to fit frame size to buffer?

I don't know whether we know the minimum width of the current toolbar so
as to not fit a frame to less than that but I suppose we could get it.
However, we can't get the minimum width of the menubar so as to not make
a frame narrower than it.  The Windows API simply does not provide it
and I wouldn't know how to approximate it.

martin

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

[Drew Adams]

> In any case I'd consider it a bug that
> `set-default-font' is allowed to resize a maximized frame.

Excuse my butting in here, esp. with little knowledge of this stuff.

Is a `maximized' frame parameter value (or whatever it is) something that
overrides other frame paramters regarding size?  Is the intention that one
cannot change the size, once a frame has been maximized (without first
unmaximizing it)?

IOW, is one supposed to first (somehow) UNmaximize the frame, before one can
change its size?  What does this mean in terms of frame parameters, from a user
point of view.

>  >> 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.

Wrt what you mention here, are the following pertinent?

http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-06/msg00120.html

http://lists.gnu.org/archive/html/emacs-devel/2004-08/msg00095.html

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <eenliu@gmail.com>, <14326@debbugs.gnu.org>
> Date: Fri, 3 May 2013 07:59:54 -0700
> 
> Is a `maximized' frame parameter value (or whatever it is) something that
> overrides other frame paramters regarding size?

No.  Whenever the frame is maximized, the size parameters are updated
accordingly.  But the action of maximizing the frame might invoke some
functions in the window manager that are not invoked by merely
resizing the screen.

> Is the intention that one cannot change the size, once a frame has
> been maximized (without first unmaximizing it)?

There's no such intention.  What Martin is arguing (I think) was that
in a maximized frame, set-default-font should alway behave as if its
2nd argument were non-nil.

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

[Eli Zaretskii]

> Date: Fri, 03 May 2013 18:48:25 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eenliu@gmail.com, 14326@debbugs.gnu.org
> 
> No.  Whenever the frame is maximized, the size parameters are updated
> accordingly.  But the action of maximizing the frame might invoke some
> functions in the window manager that are not invoked by merely
> resizing the screen.
               ^^^^^^
I meant "the frame", sorry.

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

[Drew Adams]

> > Is the intention that one cannot change the size, once a frame has
> > been maximized (without first unmaximizing it)?
> 
> There's no such intention.  What Martin is arguing (I think) was that
> in a maximized frame, set-default-font should alway behave as if its
> 2nd argument were non-nil.

Why should it?

Especially given the statement that there is no intention that one must
unmaximize a frame before changing its size.

If we impose such a behavior for `set-default-font' then it means that in that
case there _is_ such an intention: one would need to unmaximize the frame first,
before using `set-default-font' with nil KEEP-SIZE, to make a nil KEEP-SIZE
value (the default!) be respected.  Why such an exception?

(And I guess we are really talking about `set-frame-font', since
`set-default-font' has been obsolete for a long time now.  Even back in Emacs 20
`set-default-font' was just a vestigial alias for `set-frame-font'.  We can
probably stop talking about `set-default-font' now.)

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <eenliu@gmail.com>, <14326@debbugs.gnu.org>
> Date: Fri, 3 May 2013 09:26:16 -0700
> 
> > > Is the intention that one cannot change the size, once a frame has
> > > been maximized (without first unmaximizing it)?
> > 
> > There's no such intention.  What Martin is arguing (I think) was that
> > in a maximized frame, set-default-font should alway behave as if its
> > 2nd argument were non-nil.
> 
> Why should it?
> 
> Especially given the statement that there is no intention that one must
> unmaximize a frame before changing its size.
> 
> If we impose such a behavior for `set-default-font' then it means that in that
> case there _is_ such an intention: one would need to unmaximize the frame first,
> before using `set-default-font' with nil KEEP-SIZE, to make a nil KEEP-SIZE
> value (the default!) be respected.  Why such an exception?

Because the frame is maximized.

Let me turn the table and ask you: why would you want to have the
frame resized just because you changed the font?

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

[Drew Adams]

> > > > Is the intention that one cannot change the size, once 
> > > > a frame has been maximized (without first unmaximizing it)?
> > > 
> > > There's no such intention.  What Martin is arguing (I think)
> > > was that in a maximized frame, set-default-font should alway 
> > > behave as if its 2nd argument were non-nil.
> > 
> > Why should it?
> > 
> > Especially given the statement that there is no intention 
> > that one must unmaximize a frame before changing its size.
> > 
> > If we impose such a behavior for `set-default-font' then it 
> > means that in that case there _is_ such an intention: one
> > would need to unmaximize the frame first, before using
> > `set-default-font' with nil KEEP-SIZE, to make a nil KEEP-SIZE
> > value (the default!) be respected.  Why such an exception?
> 
> Because the frame is maximized.
> 
> Let me turn the table and ask you: why would you want to have the
> frame resized just because you changed the font?

Perhaps I am misunderstanding.

I thought you said that to resize the frame when it has been maximized one does
NOT need to first unmaximize it: just go ahead and change the frame parameters
that establish the new size.

And I thought you said that trying to resize the frame by using `set-frame-font'
(with nil KEEP-SIZE: the default) would be an exception to this.  To resize the
frame using `set-frame-font' you would first need to unmaximize the frame.

If I understand correctly so far then my question is why resizing the frame
using `set-frame-font' (with nil KEEP-SIZE) should be an exception.

As to why one might "want to have the frame resized just because you changed the
font": that is precisely the point of `set-frame-size' with nil KEEP-SIZE (which
is the *default* behavior, not some crazy, exceptional behavior).  (More
precisely, resizing the frame is one of the intended effects if the new font
size is different.)

`set-frame-font' resizes the frame, by default, if the new font size is
different.  That is what it is supposed to do.

Since `set-frame-font' is one way of changing the frame size, and (I think) you
said that to resize a maximized frame you need not first unmaximize it, why
should that not be the case also for resizing using `set-frame-font'?

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <eenliu@gmail.com>, <14326@debbugs.gnu.org>
> Date: Fri, 3 May 2013 11:19:25 -0700
> 
> I thought you said that to resize the frame when it has been maximized one does
> NOT need to first unmaximize it: just go ahead and change the frame parameters
> that establish the new size.

Yes.

> And I thought you said that trying to resize the frame by using `set-frame-font'
> (with nil KEEP-SIZE: the default) would be an exception to this.  To resize the
> frame using `set-frame-font' you would first need to unmaximize the frame.

Yes.

> If I understand correctly so far then my question is why resizing the frame
> using `set-frame-font' (with nil KEEP-SIZE) should be an exception.

Because the frame is maximized, which means the user _wants_ it to
stay that way.

> `set-frame-font' resizes the frame, by default, if the new font size is
> different.  That is what it is supposed to do.

I asked _you_ why would _you_ want that.  The fact that someone at
some point thought KEEP-SIZE should be nil by default, including in
maximized frames (which, btw, didn't exist at that time) does not mean
this is the absolute truth.  Do _you_ have any reasons to believe that
default is justified?

> `set-frame-font' is one way of changing the frame size

No, it's just a way to change the font.

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

[martin rudalics]

 > What Martin is arguing (I think) was that
 > in a maximized frame, set-default-font should alway behave as if its
 > 2nd argument were non-nil.

Yes.  For example, increasing the font size should not make a maximized
frame larger than the screen.  We're kidding users with such behavior.

martin

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

[Drew Adams]

>  > What Martin is arguing (I think) was that
>  > in a maximized frame, set-default-font should alway behave 
>  > as if its 2nd argument were non-nil.
> 
> Yes.  For example, increasing the font size should not make a 
> maximized frame larger than the screen.  We're kidding users
> with such behavior.

1. Your argument here applies to any size increase beyond the screen size, not
just doing that via `set-frame-font'.  So it is irrelevant as an argument why
resizing via `set-frame-font' should be an exception.

2. See what I said previously about uses of frames larger than the the screen.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <eenliu@gmail.com>, <14326@debbugs.gnu.org>
> Date: Fri, 3 May 2013 13:06:04 -0700
> 
> > For example, increasing the font size should not make a 
> > maximized frame larger than the screen.  We're kidding users
> > with such behavior.
> 
> 1. Your argument here applies to any size increase beyond the screen size, not
> just doing that via `set-frame-font'.  So it is irrelevant as an argument why
> resizing via `set-frame-font' should be an exception.

It _is_ relevant, because Martin's argument applies not only to
increasing maximized frames, but also to decreasing their size as
well, as side effect of any change except an explicit change in frame
dimensions.

IOW, when the frame is maximized, only explicitly changing its height
or width, or explicitly un-maximizing it, should ever affect the
frame's size.  Any other changes, such as font change or
adding/removing scroll bars or fringes -- should leave the frame at
the same pixel dimensions, i.e. still maximized.

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

[Drew Adams]

> > > For example, increasing the font size should not make a 
> > > maximized frame larger than the screen.  We're kidding users
> > > with such behavior.
> > 
> > 1. Your argument here applies to any size increase beyond 
> > the screen size, not just doing that via `set-frame-font'.
> > So it is irrelevant as an argument why resizing via
> > `set-frame-font' should be an exception.
> 
> It _is_ relevant, because Martin's argument applies not only to
> increasing maximized frames, but also to decreasing their size as
> well, as side effect of any change except an explicit change in frame
> dimensions.

What argument?  That is the conclusion, but what is the argument supporting it?

> IOW, when the frame is maximized, only explicitly changing its height
> or width, or explicitly un-maximizing it, should

Should why?  That's the question.  Haven't seen an answer yet.

> ever affect the frame's size.  Any other changes, such as font change or
> adding/removing scroll bars or fringes -- should

Should why?

> leave the frame at the same pixel dimensions, i.e. still maximized.

All of that just repeats the claim; it does not support it.
That is the claim for which I am asking for a supporting reason.

You have also generalized beyond just `set-frame-font' (the only exception
mentioned until now, AFAIK), BTW.  Now it is apparently not just
`set-frame-font' that is the exception but any way of resizing other than
"explicitly changing its height or width, or explicitly un-maximizing it".

My question remains, in any case: What is the _reason_ why such ways of resizing
should be neutered?  What is the _reason_ why "explicitly changing its height or
width, or explicitly un-maximizing it" should be the only way of changing the
size?

There might be a good reason for such a claim, but I've seen none advanced, so
far.  "X because X" is no support for X: it just assumes the conclusion.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <eenliu@gmail.com>, <14326@debbugs.gnu.org>
> Date: Fri, 3 May 2013 13:31:24 -0700
> 
> > > > For example, increasing the font size should not make a 
> > > > maximized frame larger than the screen.  We're kidding users
> > > > with such behavior.
> > > 
> > > 1. Your argument here applies to any size increase beyond 
> > > the screen size, not just doing that via `set-frame-font'.
> > > So it is irrelevant as an argument why resizing via
> > > `set-frame-font' should be an exception.
> > 
> > It _is_ relevant, because Martin's argument applies not only to
> > increasing maximized frames, but also to decreasing their size as
> > well, as side effect of any change except an explicit change in frame
> > dimensions.
> 
> What argument?  That is the conclusion, but what is the argument supporting it?
> 
> > IOW, when the frame is maximized, only explicitly changing its height
> > or width, or explicitly un-maximizing it, should
> 
> Should why?  That's the question.  Haven't seen an answer yet.
> 
> > ever affect the frame's size.  Any other changes, such as font change or
> > adding/removing scroll bars or fringes -- should
> 
> Should why?
> 
> > leave the frame at the same pixel dimensions, i.e. still maximized.
> 
> All of that just repeats the claim; it does not support it.

I wrote the answer to that many times, almost in every message I
posted lately in this thread: BECAUSE THE FRAME IS MAXIMIZED.

A maximized frame should stay that way for as long as the user wants
that.  The only way the user says she no longer wants a maximized
frame is (a) by explicitly changing the frame dimensions, or (b) by
changing the fullscreen frame parameter to something else.

Maximizing the frame is not just a quick way of changing its
dimensions, it's something else.  It makes the frame _qualitatively_
different.

Now, if you don't agree with that, we will have to disagree.  I've
said everything I have to say on this matter.

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

[martin rudalics]

 > A maximized frame should stay that way for as long as the user wants
 > that.  The only way the user says she no longer wants a maximized
 > frame is (a) by explicitly changing the frame dimensions, or (b) by
 > changing the fullscreen frame parameter to something else.

Thanks for the perfect description, martin

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

[Drew Adams]

> > All of that just repeats the claim; it does not support it.
> 
> I wrote the answer to that many times, almost in every message I
> posted lately in this thread: BECAUSE THE FRAME IS MAXIMIZED.
> 
> A maximized frame should stay that way for as long as the user wants
> that.  The only way the user says she no longer wants a maximized
> frame is (a) by explicitly changing the frame dimensions, or (b) by
> changing the fullscreen frame parameter to something else.
> 
> Maximizing the frame is not just a quick way of changing its
> dimensions, it's something else.  It makes the frame _qualitatively_
> different.
> 
> Now, if you don't agree with that, we will have to disagree.  I've
> said everything I have to say on this matter.

OK, it's clear.  For you, "The only way the user says she no longer wants a
maximized frame" is to explicitly unmaximize OR to explicitly change the frame
dimensions.

Where we disagree is apparently in what it means to "explicitly" make such
changes.

Changing the frame dimensions is the normal, documented, always-has-been
behavior of `set-frame-font' with no non-nil optional arguments.  That's pretty
explicit: such a call _explicitly_ changes the frame dimensions, since that is
what `set-frame-font' is documented to do.

What makes `modify-frame-parameters' changing the frame dimensions different in
your eyes from `set-frame-font' changing the frame dimensions?  They are equally
explicit.

I suppose you could argue that though the intention to change the size is
explicit in the call to `set-frame-font', the new dimensions do not appear
separately and explicitly.  They are represented by the font size (which of
course _is_ explicit).

That's rather like saying that coordinates are explicit only if they are
cartesian and not polar.  But at least I grant you that there is some
(unimportant IMO) difference between the _representation_ of the
size-specifying.

Anyway, we apparently understand each other and our disagreement now, which is
better than misunderstanding.