GNU bug report logs - #16300
24.3.50; 'M-<F10>' doesn't work always

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16300 in the body.
You can then email your comments to 16300 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; 'M-<F10>' doesn't work always
Date: Mon, 30 Dec 2013 13:02:01 +0100

Recipe from "emacs -Q":
  M-<F10> M-<F10> M-<F10>

The first time 'M-<F10>' is typed the emacs frame is maximized (OK), the
second time it is un-maximized (OK), but the third time nothing happens (it
should be maximized again).


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-29 on LEG570
Bzr revision: 115804 jan.h.d <at> swipnet.se-20131229131709-3xodjuaj5k14kpev
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

-- 
Dani Moncayo

Message #8 received at 16300 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 16300 <at> debbugs.gnu.org
Subject: Re: bug#16300: 24.3.50; 'M-<F10>' doesn't work always
Date: Sat, 04 Jan 2014 10:33:57 +0100

> Recipe from "emacs -Q":
>   M-<F10> M-<F10> M-<F10>
> 
> The first time 'M-<F10>' is typed the emacs frame is maximized (OK), the
> second time it is un-maximized (OK), but the third time nothing happens (it
> should be maximized again).

Should behave better with revision 115865 on trunk.  Please test it.

Thanks, martin

Message #11 received at 16300 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16300 <at> debbugs.gnu.org
Subject: Re: bug#16300: 24.3.50; 'M-<F10>' doesn't work always
Date: Sat, 4 Jan 2014 12:18:58 +0100

On Sat, Jan 4, 2014 at 10:33 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>> Recipe from "emacs -Q":
>>   M-<F10> M-<F10> M-<F10>
>>
>> The first time 'M-<F10>' is typed the emacs frame is maximized (OK), the
>> second time it is un-maximized (OK), but the third time nothing happens
>> (it
>> should be maximized again).
>
> Should behave better with revision 115865 on trunk.  Please test it.

It seems fixed, indeed.

And BTW, I don't know if it's due to this change, but I can't
reproduce the bug #14239 anymore with the current trunk.  So it could
be closed as well.

Thank you!

-- 
Dani Moncayo

Message #16 received at 16300-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 16300-done <at> debbugs.gnu.org
Subject: Re: bug#16300: 24.3.50; 'M-<F10>' doesn't work always
Date: Sat, 04 Jan 2014 14:43:33 +0100

> It seems fixed, indeed.

The current code still doesn't catch all possible transitions.  For
example, a FULLSCREEN_HEIGHT followed by two M-<F10>s will get you a
normalized window which is arguable not TRT but catching this without
introducing additional states seems hardly possible.  Here I do

(defun toggle-full-height ()
  (interactive)
  (if (eq (frame-parameter nil 'fullscreen) 'fullheight)
      (set-frame-parameter nil 'fullscreen 'fullnone)
    (set-frame-parameter nil 'fullscreen 'fullheight)))

which IMO is the best way to use the FULLHEIGHT feature.

I'll close this bug.

> And BTW, I don't know if it's due to this change, but I can't
> reproduce the bug #14239 anymore with the current trunk.

The old code used SetWindowPos which according to

http://msdn.microsoft.com/en-us/library/windows/desktop/ms632611%28v=vs.85%29.aspx

should not be used:

  The coordinates used in a WINDOWPLACEMENT structure should be used
  only by the GetWindowPlacement and SetWindowPlacement
  functions. Passing workspace coordinates to functions which expect
  screen coordinates (such as SetWindowPos) will result in the window
  appearing in the wrong location. For example, if the taskbar is at the
  top of the screen, saving window coordinates using GetWindowPlacement
  and restoring them using SetWindowPos causes the window to appear to
  "creep" up the screen.

> So it could
> be closed as well.

Please do that.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.