GNU bug report logs -
#25542
25.1; Restoring the frame from fullscreen to maximized
Previous Next
Reported by: Dani Moncayo <dmoncayo <at> gmail.com>
Date: Thu, 26 Jan 2017 08:16:02 UTC
Severity: normal
Found in version 25.1
Done: Ken Brown <kbrown <at> cornell.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25542 in the body.
You can then email your comments to 25542 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 26 Jan 2017 08:16:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dani Moncayo <dmoncayo <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 26 Jan 2017 08:16:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Recipe from "emacs -Q"
1. Maximize the frame using the mouse -- for example, on MS-Windows,
either click on the "maximize" button or double click on the title
bar.
2. Switch to fullscreen by pressing F11.
3. Press F11 again.
Expected behavior: The frame goes to its previous state (i.e. maximized).
Observed behavior: The frame is not maximized (it is smaller that a
maximized one, both in height and width).
I'm using the Emacs distributed with cygwin, which uses the native
MS-Windows GUI (package "emacs-w32"):
In GNU Emacs 25.1.1 (x86_64-unknown-cygwin)
of 2016-09-17 built on desktop-new
Windowing system distributor 'Microsoft Corp.', version 10.0.10586
Configured using:
'configure
--srcdir=/home/kbrown/src/cygemacs/emacs-25.1-1.x86_64/src/emacs-25.1
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/emacs --htmldir=/usr/share/doc/emacs/html -C
--with-w32 'CFLAGS=-ggdb -O2 -pipe -Wimplicit-function-declaration
-fdebug-prefix-map=/home/kbrown/src/cygemacs/emacs-25.1-1.x86_64/build=/usr/src/debug/emacs-25.1-1
-fdebug-prefix-map=/home/kbrown/src/cygemacs/emacs-25.1-1.x86_64/src/emacs-25.1=/usr/src/debug/emacs-25.1-1'
CPPFLAGS= LDFLAGS='
Configured features:
XPM JPEG TIFF GIF PNG IMAGEMAGICK SOUND DBUS NOTIFY ACL GNUTLS LIBXML2
ZLIB TOOLKIT_SCROLL_BARS
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 26 Jan 2017 09:53:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> Recipe from "emacs -Q"
>
> 1. Maximize the frame using the mouse -- for example, on MS-Windows,
> either click on the "maximize" button or double click on the title
> bar.
>
> 2. Switch to fullscreen by pressing F11.
>
> 3. Press F11 again.
>
>
> Expected behavior: The frame goes to its previous state (i.e. maximized).
This is the behavior I get with my MinGW builds on Windows XP.
> Observed behavior: The frame is not maximized (it is smaller that a
> maximized one, both in height and width).
>
>
> I'm using the Emacs distributed with cygwin, which uses the native
> MS-Windows GUI (package "emacs-w32"):
What is that package "emacs-w32"?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 26 Jan 2017 10:21:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 25542 <at> debbugs.gnu.org (full text, mbox):
>> I'm using the Emacs distributed with cygwin, which uses the native
>> MS-Windows GUI (package "emacs-w32"):
>
> What is that package "emacs-w32"?
I'm not sure I understand your question, so my answer may be
trivial/useless to you, but anyway: Cygwin is a distribution of
software organized in packages. The name of one of those packages is
"emacs-w32" (you can search for it in the cygwin package manager).
Well, that is the package which includes the Emacs binary I'm using.
It's basically a build of Emacs made for the Cygwin platform, but
modified to use the native MS-Windows GUI, instead of X-Window or
another toolkit like GTK+.
HTH.
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 26 Jan 2017 10:55:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 25542 <at> debbugs.gnu.org (full text, mbox):
BTW, I forgot to mention that my OS (on which Cygwin is installed) is
MS-Windows 10 Enterprise.
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 26 Jan 2017 14:01:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 25542 <at> debbugs.gnu.org (full text, mbox):
>> What is that package "emacs-w32"?
>
> I'm not sure I understand your question, so my answer may be
> trivial/useless to you, but anyway: Cygwin is a distribution of
> software organized in packages. The name of one of those packages is
> "emacs-w32" (you can search for it in the cygwin package manager).
> Well, that is the package which includes the Emacs binary I'm using.
I don't have Cygwin installed so I doubt that using its package manager
would make much sense for me. Anyway, I suppose it provides a w32
executable, say emacs-w32.exe and some additional libraries. I was a
bit confused by the term "package".
> It's basically a build of Emacs made for the Cygwin platform, but
> modified to use the native MS-Windows GUI, instead of X-Window or
> another toolkit like GTK+.
We would probably have to look at these "modifications" in order to find
out what happens. Meanwhile a few questions:
(1) What is the appearance of the maximize button after step 3? Does it
show two overlapping windows or one large window?
(2) How do the frames from before step 2 and after step 3 differ?
Please use M-: (frame-geometry) and post the ‘outer-position’ and
‘outer-size’ values.
(3) Apart from the problem you reported do
M-: (set-frame-parameter nil 'fullscreen 'maximized)
and clicking on the maximize button of the title bar produce frames
with the same size and position?
(4) Does setting ‘frame-resize-pixelwise’ to t change anything?
(5) Can you try with a native Windows build or a GTK build and see
whether they exhibit the same problem?
> BTW, I forgot to mention that my OS (on which Cygwin is installed) is
> MS-Windows 10 Enterprise.
Can anyone with a native build on Windows 10 reproduce the problem?
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 26 Jan 2017 15:44:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jan 26, 2017 at 9:00 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>
>> BTW, I forgot to mention that my OS (on which Cygwin is installed) is
>> MS-Windows 10 Enterprise.
>
> Can anyone with a native build on Windows 10 reproduce the problem?
Does not reproduce for me on Windows 10 using the native 25.1 release
or master from a few days ago.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 26 Jan 2017 16:09:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 26 Jan 2017 10:51:48 +0100
> From: martin rudalics <rudalics <at> gmx.at>
>
> > Recipe from "emacs -Q"
> >
> > 1. Maximize the frame using the mouse -- for example, on MS-Windows,
> > either click on the "maximize" button or double click on the title
> > bar.
> >
> > 2. Switch to fullscreen by pressing F11.
> >
> > 3. Press F11 again.
> >
> >
> > Expected behavior: The frame goes to its previous state (i.e. maximized).
>
> This is the behavior I get with my MinGW builds on Windows XP.
As do I. I also tested on Windows 7, and I see the same expected
behavior there.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 26 Jan 2017 16:11:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> users.sourceforge.net>
> Date: Thu, 26 Jan 2017 10:43:29 -0500
> Cc: 25542 <at> debbugs.gnu.org
>
> On Thu, Jan 26, 2017 at 9:00 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> >
> >> BTW, I forgot to mention that my OS (on which Cygwin is installed) is
> >> MS-Windows 10 Enterprise.
> >
> > Can anyone with a native build on Windows 10 reproduce the problem?
>
> Does not reproduce for me on Windows 10 using the native 25.1 release
> or master from a few days ago.
That's strange, since the Cygwin w32 build is supposed to use the same
code as the native build for its GUI display backend.
Maybe Dani could test a native build on the same system?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 26 Jan 2017 17:50:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 25542 <at> debbugs.gnu.org (full text, mbox):
Hello,
I've just realized another detail required to reproduce the problem:
the Windows taskbar must be docked to the left side of the screen.
(If I move the taskbar to the bottom side --its default position--,
then I cannot reproduce the problem).
I've just reproduced the problem also with a native MS-Windows build
of Emacs (a recent build from the emacs-25 branch):
In GNU Emacs 25.1.90.1 (i686-pc-mingw32)
of 2016-12-28 built on LEG570
Repository revision: 697167b5432a89db009238cf5cbddc61e69ad339
Windowing system distributor 'Microsoft Corp.', version 10.0.14393
Configured using:
'configure --host=i686-pc-mingw32'
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 26 Jan 2017 18:03:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jan 26, 2017 at 12:49 PM, Dani Moncayo <dmoncayo <at> gmail.com> wrote:
> Hello,
>
> I've just realized another detail required to reproduce the problem:
> the Windows taskbar must be docked to the left side of the screen.
> (If I move the taskbar to the bottom side --its default position--,
> then I cannot reproduce the problem).
>
> I've just reproduced the problem also with a native MS-Windows build
> of Emacs (a recent build from the emacs-25 branch):
I can confirm with 25.1 and master. Oddly enough, having the taskbar
on the *right* side of screen (which I usually do) doesn't trigger
this issue either.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 26 Jan 2017 19:07:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> I've just realized another detail required to reproduce the problem:
> the Windows taskbar must be docked to the left side of the screen.
> (If I move the taskbar to the bottom side --its default position--,
> then I cannot reproduce the problem).
>
> I've just reproduced the problem also with a native MS-Windows build
> of Emacs (a recent build from the emacs-25 branch):
What does M-: (w32-display-monitor-attributes-list) return when your
taskbar is on the left?
Do other applications handle your scenario correctly? Firefox?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 07:55:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 25542 <at> debbugs.gnu.org (full text, mbox):
Hi Martin,
> What does M-: (w32-display-monitor-attributes-list) return when your
> taskbar is on the left?
(((geometry 0 0 1600 900) (workarea 62 0 1538 900) (mm-size 443 249)
(name . "\\\\.\\DISPLAY1") (frames #<frame emacs <at> CPX-L6Q03C31DOX
0x10100bc30>)))
> Do other applications handle your scenario correctly? Firefox?
I've just tested the chrome browser, and the File Explorer. Both
behave correctly.
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 08:04:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> (1) What is the appearance of the maximize button after step 3? Does it
> show two overlapping windows or one large window?
The button shows a single box.- i.e., the window state is _not_ maximized.
> (2) How do the frames from before step 2 and after step 3 differ?
> Please use M-: (frame-geometry) and post the ‘outer-position’ and
> ‘outer-size’ values.
The frames are exactly equal. Both in size and positon on the screen.
> (3) Apart from the problem you reported do
>
> M-: (set-frame-parameter nil 'fullscreen 'maximized)
>
> and clicking on the maximize button of the title bar produce frames
> with the same size and position?
Yes. Both are maximized frames, which take up the entire screen
except the taskbar.
> (4) Does setting ‘frame-resize-pixelwise’ to t change anything?
No (the problem persists after setting that variable to t).
> (5) Can you try with a native Windows build or a GTK build and see
> whether they exhibit the same problem?
This was answered in a previous mail. The problem is reproducible
also with a native windows build.
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 08:18:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Date: Fri, 27 Jan 2017 09:03:41 +0100
> Cc: 25542 <at> debbugs.gnu.org
>
> > (2) How do the frames from before step 2 and after step 3 differ?
> > Please use M-: (frame-geometry) and post the ‘outer-position’ and
> > ‘outer-size’ values.
>
> The frames are exactly equal. Both in size and positon on the screen.
This seems to contradict your original report, where you said the two
frames had different sizes. Or maybe you are saying that the above 2
functions return the same values, but the actual values are different?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 08:24:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 25542 <at> debbugs.gnu.org (full text, mbox):
>> > (2) How do the frames from before step 2 and after step 3 differ?
>> > Please use M-: (frame-geometry) and post the ‘outer-position’ and
>> > ‘outer-size’ values.
>>
>> The frames are exactly equal. Both in size and positon on the screen.
>
> This seems to contradict your original report, where you said the two
> frames had different sizes.
Mmmm I said this:
Observed behavior: The frame is not maximized (it is smaller that a
maximized one, both in height and width).
So I don't see any contradiction - What I wanted to express in both
cases is that the Emacs frame, after the final step, is _not_
maximized (as it should be).
IOW: in step 3, the frame should have been switched from fullscreen to
maximized, but it actually switched to the initial status/size (i.e.
not maximized).
HTH
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 09:19:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 25542 <at> debbugs.gnu.org (full text, mbox):
>> What does M-: (w32-display-monitor-attributes-list) return when your
>> taskbar is on the left?
>
> (((geometry 0 0 1600 900) (workarea 62 0 1538 900) (mm-size 443 249)
> (name . "\\\\.\\DISPLAY1") (frames #<frame emacs <at> CPX-L6Q03C31DOX
> 0x10100bc30>)))
So the taskbar is recognized correctly.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 09:20:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 25542 <at> debbugs.gnu.org (full text, mbox):
>> (1) What is the appearance of the maximize button after step 3? Does it
>> show two overlapping windows or one large window?
>
> The button shows a single box.- i.e., the window state is _not_ maximized.
This should not happen. Does it show the two boxes after step 3 with
the taskbar placed on any of the three other sides of your screen?
>> (2) How do the frames from before step 2 and after step 3 differ?
>> Please use M-: (frame-geometry) and post the ‘outer-position’ and
>> ‘outer-size’ values.
>
> The frames are exactly equal. Both in size and positon on the screen.
Please post the values, maybe they can give us a clue.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 09:26:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 27, 2017 at 10:19 AM, martin rudalics <rudalics <at> gmx.at> wrote:
>>> (1) What is the appearance of the maximize button after step 3? Does it
>>> show two overlapping windows or one large window?
>>
>> The button shows a single box.- i.e., the window state is _not_ maximized.
>
> This should not happen. Does it show the two boxes after step 3 with
> the taskbar placed on any of the three other sides of your screen?
I've just tried with the taskbar on the bottom side, and yes, it does
show the two boxes (i.e., maximized frame, expected behavior).
>>> (2) How do the frames from before step 2 and after step 3 differ?
>>> Please use M-: (frame-geometry) and post the ‘outer-position’ and
>>> ‘outer-size’ values.
>>
>> The frames are exactly equal. Both in size and positon on the screen.
>
> Please post the values, maybe they can give us a clue.
In both cases (before step 2 and after step 3), (frame-geometry) outputs this:
((outer-position 192 . 130) (outer-size 689 . 671)
(external-border-size 8 . 8) (title-bar-size 651 . 23)
(menu-bar-external . t) (menu-bar-size 673 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 689 . 36)
(internal-border-width . 0))
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 09:32:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 25542 <at> debbugs.gnu.org (full text, mbox):
BTW/FWIW: I've now tried to reproduce the problem with the taskbar
placed at every possible side (left, right, top, bottom). I see the
problem with the taskbar in the left or top. I do _not_ see the
problem with the taskbar in the bottom or right.
HTH
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 09:35:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> I've just tried with the taskbar on the bottom side, and yes, it does
> show the two boxes (i.e., maximized frame, expected behavior).
Can you try the other two sides as well?
> In both cases (before step 2 and after step 3), (frame-geometry) outputs this:
>
> ((outer-position 192 . 130)
This completely contradicts what I have seen till now: outer-position
should be negative on at least one side (in your case the value 130
should be something like -4 accounting for the external border width).
What's even more strange is that it shows this value before step 2.
This seems to indicate that the frame was not maximized before step 2
either. What are the respective values with the taskbar on bottom?
> (outer-size 689 . 671)
Is it true that your screen is almost square and has so few pixels?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 09:51:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> BTW/FWIW: I've now tried to reproduce the problem with the taskbar
> placed at every possible side (left, right, top, bottom). I see the
> problem with the taskbar in the left or top. I do _not_ see the
> problem with the taskbar in the bottom or right.
That sounds at least consistent. Please post also the ‘frame-geometry’
figures for all three cases and `w32-display-monitor-attributes-list' to
know the height of the taskbar when it's at bottom/top.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 10:02:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 25542 <at> debbugs.gnu.org (full text, mbox):
>> In both cases (before step 2 and after step 3), (frame-geometry) outputs
>> this:
>>
>> ((outer-position 192 . 130)
I'm afraid I've been imprecise here. I was comparing the initial and
final scenarios (i.e. before step 1 and after step 3).
So, I'll now post the values you wanted:
** Before step 2 (i.e. just after maximizing the frame with the mouse):
((outer-position 54 . -8) (outer-size 1554 . 916)
(external-border-size 8 . 8) (title-bar-size 1516 . 23)
(menu-bar-external . t) (menu-bar-size 1538 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 1554 . 36)
(internal-border-width . 0))
** After step 3 (i.e. just after pressing F11 a second time)
((outer-position 192 . 130) (outer-size 689 . 671)
(external-border-size 8 . 8) (title-bar-size 651 . 23)
(menu-bar-external . t) (menu-bar-size 673 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 689 . 36)
(internal-border-width . 0))
These values (after final step) are the same I get at the very
beginning (just after "emacs -Q").
Sorry for the confusion.
>> (outer-size 689 . 671)
>
> Is it true that your screen is almost square and has so few pixels?
No, my screen resolution is 1600 x 900 pixels.
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 10:23:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> Please post also the ‘frame-geometry’
> figures for all three cases and `w32-display-monitor-attributes-list' to
> know the height of the taskbar when it's at bottom/top.
OK, here is the ouput of (frame-geometry) when the Emacs frame is
maximized, for each possible position of the taskbar:
TOP:
((outer-position -8 . 22) (outer-size 1616 . 886)
(external-border-size 8 . 8) (title-bar-size 1578 . 23)
(menu-bar-external . t) (menu-bar-size 1600 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 1616 . 36)
(internal-border-width . 0))
RIGHT:
((outer-position -8 . -8) (outer-size 1554 . 916)
(external-border-size 8 . 8) (title-bar-size 1516 . 23)
(menu-bar-external . t) (menu-bar-size 1538 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 1554 . 36)
(internal-border-width . 0))
BOTTOM:
((outer-position -8 . -8) (outer-size 1616 . 886)
(external-border-size 8 . 8) (title-bar-size 1578 . 23)
(menu-bar-external . t) (menu-bar-size 1600 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 1616 . 36)
(internal-border-width . 0))
LEFT:
((outer-position 54 . -8) (outer-size 1554 . 916)
(external-border-size 8 . 8) (title-bar-size 1516 . 23)
(menu-bar-external . t) (menu-bar-size 1538 . 20) (tool-bar-external)
(tool-bar-position . top) (tool-bar-size 1554 . 36)
(internal-border-width . 0))
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 10:28:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> OK, here is the ouput of (frame-geometry) when the Emacs frame is
> maximized, for each possible position of the taskbar:
And here is the output of (w32-display-monitor-attributes-list) in
those same cases:
TOP:
(((geometry 0 0 1600 900) (workarea 0 30 1600 870) (mm-size 443 249)
(name . "\\\\.\\DISPLAY1") (frames #<frame emacs <at> CPX-L6Q03C31DOX
0x10100bc30>)))
RIGHT:
(((geometry 0 0 1600 900) (workarea 0 0 1538 900) (mm-size 443 249)
(name . "\\\\.\\DISPLAY1") (frames #<frame emacs <at> CPX-L6Q03C31DOX
0x10100bc30>)))
BOTTOM:
(((geometry 0 0 1600 900) (workarea 0 0 1600 870) (mm-size 443 249)
(name . "\\\\.\\DISPLAY1") (frames #<frame emacs <at> CPX-L6Q03C31DOX
0x10100bc30>)))
LEFT:
(((geometry 0 0 1600 900) (workarea 62 0 1538 900) (mm-size 443 249)
(name . "\\\\.\\DISPLAY1") (frames #<frame emacs <at> CPX-L6Q03C31DOX
0x10100bc30>)))
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 13:48:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> ** Before step 2 (i.e. just after maximizing the frame with the mouse):
>
> ((outer-position 54 . -8) (outer-size 1554 . 916)
54 because the frame's left outer edge is by external-border-size
pixels left of the taskbar's right end which according to
> LEFT:
> (((geometry 0 0 1600 900) (workarea 62 0 1538 900) (mm-size 443 249)
> (name . "\\\\.\\DISPLAY1") (frames #<frame emacs <at> CPX-L6Q03C31DOX
> 0x10100bc30>)))
is at 62. -8 because the frame's top edge is by external-border-size
pixels above the display.
> (external-border-size 8 . 8) (title-bar-size 1516 . 23)
> (menu-bar-external . t) (menu-bar-size 1538 . 20) (tool-bar-external)
> (tool-bar-position . top) (tool-bar-size 1554 . 36)
> (internal-border-width . 0))
>
> ** After step 3 (i.e. just after pressing F11 a second time)
>
> ((outer-position 192 . 130) (outer-size 689 . 671)
> (external-border-size 8 . 8) (title-bar-size 651 . 23)
> (menu-bar-external . t) (menu-bar-size 673 . 20) (tool-bar-external)
> (tool-bar-position . top) (tool-bar-size 689 . 36)
> (internal-border-width . 0))
All these values are consistent now and indicate that the frame has
returned to its normal state after step 3.
> These values (after final step) are the same I get at the very
> beginning (just after "emacs -Q").
Everything seems clear - the bug is all mine. Windows just told us that
the frame was maximized but the simple hack in w32.term.c
case SIZE_MAXIMIZED:
...
/* Windows can send us a SIZE_MAXIMIZED message even
when fullscreen is fullboth. The following is a
simple hack to check that based on the fact that
only a maximized fullscreen frame should have both
top/left outside the screen. */
if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen, Qfullheight)
|| NILP (fullscreen))
{
int x, y;
x_real_positions (f, &x, &y);
if (x < 0 && y < 0)
store_frame_param (f, Qfullscreen, Qmaximized);
}
fails becaue either x (in your case) or y (in the taskbar at top case)
are greater zero. (I boldly assume that NILP (fullscreen) held, maybe
Noam can verify - I never move my taskbar.) I could replace
if (x < 0 && y < 0)
with
if (x < 0 || y < 0)
to handle the two cases but that check appears downright silly and will
fail anyway for border-less, maximized frames. I must devise something
better.
Thanks for all the information you sent, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 27 Jan 2017 18:51:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 25542 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Jan 27, 2017 at 8:47 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> Everything seems clear - the bug is all mine. Windows just told us that
> the frame was maximized but the simple hack in w32.term.c
>
> case SIZE_MAXIMIZED:
> ...
> /* Windows can send us a SIZE_MAXIMIZED message even
> when fullscreen is fullboth. The following is a
> simple hack to check that based on the fact that
> only a maximized fullscreen frame should have both
> top/left outside the screen. */
> if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen,
> Qfullheight)
> || NILP (fullscreen))
> {
> int x, y;
>
> x_real_positions (f, &x, &y);
> if (x < 0 && y < 0)
> store_frame_param (f, Qfullscreen, Qmaximized);
> }
>
> fails becaue either x (in your case) or y (in the taskbar at top case)
> are greater zero. (I boldly assume that NILP (fullscreen) held, maybe
> Noam can verify - I never move my taskbar.)
Your assumption is correct. I added some message calls to master (as
in the attached diff). With the taskbar on the left I got:
SIZE_MAXIMIZED, fullscreen = nil
SIZE_MAXIMIZED, x = 54, y = -8
on the maximize, and
SIZE_MAXIMIZED, fullscreen = fullboth
on hitting f11 the first time. Nothing the second time (when Emacs
incorrectly switches to non-maximized state).
With the taskbar on top it's the same except x = -8, y = 22 (when
taskbar is on the right or botton both x and y are -8 and the the
second f11 produces the same message as maximizing).
[w32term.c.msg.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 28 Jan 2017 08:03:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> Your assumption is correct. I added some message calls to master (as
> in the attached diff). With the taskbar on the left I got:
>
> SIZE_MAXIMIZED, fullscreen = nil
> SIZE_MAXIMIZED, x = 54, y = -8
>
> on the maximize, and
>
> SIZE_MAXIMIZED, fullscreen = fullboth
>
> on hitting f11 the first time. Nothing the second time (when Emacs
> incorrectly switches to non-maximized state).
>
> With the taskbar on top it's the same except x = -8, y = 22 (when
> taskbar is on the right or botton both x and y are -8 and the the
> second f11 produces the same message as maximizing).
Thank you very much for checking. I suppose that replacing
if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen, Qfullheight)
|| NILP (fullscreen))
{
int x, y;
x_real_positions (f, &x, &y);
if (x < 0 && y < 0)
store_frame_param (f, Qfullscreen, Qmaximized);
}
with
store_frame_param (f, Qfullscreen, Qmaximized);
should work because I doubt that "Windows can send us a SIZE_MAXIMIZED
message even when fullscreen is fullboth" can happen but who knows ...
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 04 Sep 2020 12:34:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 25542 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
>> With the taskbar on top it's the same except x = -8, y = 22 (when
>> taskbar is on the right or botton both x and y are -8 and the the
>> second f11 produces the same message as maximizing).
>
> Thank you very much for checking. I suppose that replacing
>
> if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen, Qfullheight)
> || NILP (fullscreen))
> {
> int x, y;
>
> x_real_positions (f, &x, &y);
> if (x < 0 && y < 0)
> store_frame_param (f, Qfullscreen, Qmaximized);
> }
>
> with
>
> store_frame_param (f, Qfullscreen, Qmaximized);
>
> should work because I doubt that "Windows can send us a SIZE_MAXIMIZED
> message even when fullscreen is fullboth" can happen but who knows ...
Reading this thread, it seems like the problem was analysed thoroughly,
but this was the final message in the thread. Did anybody try this
solution to see whether it fixes the problem, or has the problem been
fixed in a different way over the years?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 04 Sep 2020 17:54:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On Fri, Sep 4, 2020 at 2:33 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> [...]
> Did anybody try this
> solution to see whether it fixes the problem, or has the problem been
> fixed in a different way over the years?
I've just seen that the bug is still present in the version I'm using:
GNU Emacs 27.1 (build 1, x86_64-pc-cygwin)
of 2020-08-11
(Sorry, I don't have currently a suitable build environment for Emacs,
so I can't try the proposed fix)
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 05 Sep 2020 06:48:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Date: Fri, 4 Sep 2020 19:50:59 +0200
> Cc: 25542 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> users.sourceforge.net>
>
> On Fri, Sep 4, 2020 at 2:33 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> > [...]
> > Did anybody try this
> > solution to see whether it fixes the problem, or has the problem been
> > fixed in a different way over the years?
>
> I've just seen that the bug is still present in the version I'm using:
>
> GNU Emacs 27.1 (build 1, x86_64-pc-cygwin)
> of 2020-08-11
This problem is specific to the Cywgin's w32 build, so someone who
uses it should try the patch.
I cannot say that I'm happy with the patch, though: it affects the
native w32 build as well, where the problem doesn't happen in the
first place. If it helps, maybe we should make the change conditional
on CYGWIN or something.
Ken, can you try the patch, please? And WDYT about the solution?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 05 Sep 2020 12:02:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On Sat, Sep 5, 2020 at 8:47 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> [...]
> This problem is specific to the Cywgin's w32 build
> [...]
I've just downloaded a native w32 build [1] and I've run it on my
system (MS Windows 10 Enterprise). I see the same problem with this
native build.
[1] http://ftp.rediris.es/mirror/GNU/emacs/windows/emacs-27/emacs-27.1-x86_64.zip
This is GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
of 2020-08-21
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 05 Sep 2020 12:18:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Date: Sat, 5 Sep 2020 13:59:46 +0200
> Cc: Ken Brown <kbrown <at> cornell.edu>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 25542 <at> debbugs.gnu.org,
> Noam Postavsky <npostavs <at> users.sourceforge.net>, martin rudalics <rudalics <at> gmx.at>
>
> > This problem is specific to the Cywgin's w32 build
> > [...]
>
> I've just downloaded a native w32 build [1] and I've run it on my
> system (MS Windows 10 Enterprise). I see the same problem with this
> native build.
Then we have a reproducibility problem, because I don't see this with
the native build, and neither did Martin at the time (see his initial
response to the original bug report).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 05 Sep 2020 12:22:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On Sat, Sep 5, 2020 at 2:17 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> [...]
> Then we have a reproducibility problem, because I don't see this with
> the native build, and neither did Martin at the time (see his initial
> response to the original bug report).
Did you try with the taskbar attached to the left side of the screen?
That is required to trigger the problem, as I said in this message:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25542#29
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 05 Sep 2020 12:32:01 GMT)
Full text and
rfc822 format available.
Message #104 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Date: Sat, 5 Sep 2020 14:19:10 +0200
> Cc: Ken Brown <kbrown <at> cornell.edu>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 25542 <at> debbugs.gnu.org,
> Noam Postavsky <npostavs <at> users.sourceforge.net>, martin rudalics <rudalics <at> gmx.at>
>
> On Sat, Sep 5, 2020 at 2:17 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > [...]
> > Then we have a reproducibility problem, because I don't see this with
> > the native build, and neither did Martin at the time (see his initial
> > response to the original bug report).
>
> Did you try with the taskbar attached to the left side of the screen?
No. And it isn't clear to me whether Martin did.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 05 Sep 2020 12:35:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On Sat, Sep 5, 2020 at 2:30 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Dani Moncayo <dmoncayo <at> gmail.com>
> > Date: Sat, 5 Sep 2020 14:19:10 +0200
> > Cc: Ken Brown <kbrown <at> cornell.edu>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 25542 <at> debbugs.gnu.org,
> > Noam Postavsky <npostavs <at> users.sourceforge.net>, martin rudalics <rudalics <at> gmx.at>
> >
> > On Sat, Sep 5, 2020 at 2:17 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > [...]
> > > Then we have a reproducibility problem, because I don't see this with
> > > the native build, and neither did Martin at the time (see his initial
> > > response to the original bug report).
> >
> > Did you try with the taskbar attached to the left side of the screen?
>
> No. And it isn't clear to me whether Martin did.
OK. So, are you able to reproduce the problem now?
BTW, another detail I've just noticed to reproduce the problem: in the
"taskbar settings" the flag "Automatically hide the taskbar" must be
turned off.
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 05 Sep 2020 12:50:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Date: Sat, 5 Sep 2020 14:32:04 +0200
> Cc: Ken Brown <kbrown <at> cornell.edu>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 25542 <at> debbugs.gnu.org,
> Noam Postavsky <npostavs <at> users.sourceforge.net>, martin rudalics <rudalics <at> gmx.at>
>
> > > Did you try with the taskbar attached to the left side of the screen?
> >
> > No. And it isn't clear to me whether Martin did.
>
> OK. So, are you able to reproduce the problem now?
I didn't try. Not enough time, sorry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 05 Sep 2020 15:11:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On 9/5/2020 8:32 AM, Dani Moncayo wrote:
> On Sat, Sep 5, 2020 at 2:30 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>>> From: Dani Moncayo <dmoncayo <at> gmail.com>
>>> Date: Sat, 5 Sep 2020 14:19:10 +0200
>>> Cc: Ken Brown <kbrown <at> cornell.edu>, Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 25542 <at> debbugs.gnu.org,
>>> Noam Postavsky <npostavs <at> users.sourceforge.net>, martin rudalics <rudalics <at> gmx.at>
>>>
>>> On Sat, Sep 5, 2020 at 2:17 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>> [...]
>>>> Then we have a reproducibility problem, because I don't see this with
>>>> the native build, and neither did Martin at the time (see his initial
>>>> response to the original bug report).
>>>
>>> Did you try with the taskbar attached to the left side of the screen?
>>
>> No. And it isn't clear to me whether Martin did.
>
> OK. So, are you able to reproduce the problem now?
>
> BTW, another detail I've just noticed to reproduce the problem: in the
> "taskbar settings" the flag "Automatically hide the taskbar" must be
> turned off.
I can reproduce the problem on the Cygwin w32 build, but Martin's suggestion
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25542#83) doesn't fix it. He
suggested the following, if I understand correctly:
diff --git a/src/w32term.c b/src/w32term.c
index 76cf6bd696..c7da95528b 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -5454,15 +5454,7 @@ w32_read_socket (struct terminal *terminal,
simple hack to check that based on the fact that
only a maximized fullscreen frame should have both
top/left outside the screen. */
- if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen, Qfullheight)
- || NILP (fullscreen))
- {
- int x, y;
-
- w32_real_positions (f, &x, &y);
- if (x < 0 && y < 0)
- store_frame_param (f, Qfullscreen, Qmaximized);
- }
+ store_frame_param (f, Qfullscreen, Qmaximized);
}
break;
If I make this change and follow Dani's recipe from the original bug report, the
second F11 press doesn't restore the previous state. Instead, the frame appears
to get slightly smaller for an instant and then immediately reverts to
fullscreen mode.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 05 Sep 2020 16:09:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 25542 <at> debbugs.gnu.org,
> Noam Postavsky <npostavs <at> users.sourceforge.net>,
> martin rudalics <rudalics <at> gmx.at>
> From: Ken Brown <kbrown <at> cornell.edu>
> Date: Sat, 5 Sep 2020 11:10:31 -0400
>
> diff --git a/src/w32term.c b/src/w32term.c
> index 76cf6bd696..c7da95528b 100644
> --- a/src/w32term.c
> +++ b/src/w32term.c
> @@ -5454,15 +5454,7 @@ w32_read_socket (struct terminal *terminal,
> simple hack to check that based on the fact that
> only a maximized fullscreen frame should have both
> top/left outside the screen. */
> - if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen, Qfullheight)
> - || NILP (fullscreen))
> - {
> - int x, y;
> -
> - w32_real_positions (f, &x, &y);
> - if (x < 0 && y < 0)
> - store_frame_param (f, Qfullscreen, Qmaximized);
> - }
> + store_frame_param (f, Qfullscreen, Qmaximized);
> }
>
> break;
>
> If I make this change and follow Dani's recipe from the original bug report, the
> second F11 press doesn't restore the previous state. Instead, the frame appears
> to get slightly smaller for an instant and then immediately reverts to
> fullscreen mode.
Thanks for testing. It sounds like the proposed change leaves the
original incorrect behavior unchanged, so we need to look for some
different way of fixing this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 05 Sep 2020 16:12:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On 9/5/2020 12:07 PM, Eli Zaretskii wrote:
>> Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 25542 <at> debbugs.gnu.org,
>> Noam Postavsky <npostavs <at> users.sourceforge.net>,
>> martin rudalics <rudalics <at> gmx.at>
>> From: Ken Brown <kbrown <at> cornell.edu>
>> Date: Sat, 5 Sep 2020 11:10:31 -0400
>>
>> diff --git a/src/w32term.c b/src/w32term.c
>> index 76cf6bd696..c7da95528b 100644
>> --- a/src/w32term.c
>> +++ b/src/w32term.c
>> @@ -5454,15 +5454,7 @@ w32_read_socket (struct terminal *terminal,
>> simple hack to check that based on the fact that
>> only a maximized fullscreen frame should have both
>> top/left outside the screen. */
>> - if (EQ (fullscreen, Qfullwidth) || EQ (fullscreen, Qfullheight)
>> - || NILP (fullscreen))
>> - {
>> - int x, y;
>> -
>> - w32_real_positions (f, &x, &y);
>> - if (x < 0 && y < 0)
>> - store_frame_param (f, Qfullscreen, Qmaximized);
>> - }
>> + store_frame_param (f, Qfullscreen, Qmaximized);
>> }
>>
>> break;
>>
>> If I make this change and follow Dani's recipe from the original bug report, the
>> second F11 press doesn't restore the previous state. Instead, the frame appears
>> to get slightly smaller for an instant and then immediately reverts to
>> fullscreen mode.
>
> Thanks for testing. It sounds like the proposed change leaves the
> original incorrect behavior unchanged, so we need to look for some
> different way of fixing this.
It's not unchanged, it's just wrong in a different way. Previously the second
F11 resulted in an unmaximized frame.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 05 Sep 2020 16:43:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> Cc: dmoncayo <at> gmail.com, larsi <at> gnus.org, 25542 <at> debbugs.gnu.org,
> npostavs <at> users.sourceforge.net, rudalics <at> gmx.at
> From: Ken Brown <kbrown <at> cornell.edu>
> Date: Sat, 5 Sep 2020 12:10:59 -0400
>
> > Thanks for testing. It sounds like the proposed change leaves the
> > original incorrect behavior unchanged, so we need to look for some
> > different way of fixing this.
>
> It's not unchanged, it's just wrong in a different way. Previously the second
> F11 resulted in an unmaximized frame.
You are right, sorry for my confusion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Wed, 09 Sep 2020 08:46:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> I've just downloaded a native w32 build [1] and I've run it on my
> system (MS Windows 10 Enterprise). I see the same problem with this
> native build.
Can you please run under gdb with a breakpoint in w32fullscreen_hook of
w32term.c suitably in here
else if (f->want_fullscreen == FULLSCREEN_MAXIMIZED)
{
if (prev_fsmode == FULLSCREEN_BOTH || prev_fsmode == FULLSCREEN_WIDTH
|| prev_fsmode == FULLSCREEN_HEIGHT)
/* Make window normal since otherwise the subsequent
maximization might fail in some cases. */
ShowWindow (hwnd, SW_SHOWNORMAL);
ShowWindow (hwnd, SW_MAXIMIZE);
}
and tell us how the frame appears immediately after the ShowWindow
calls. Here the first call makes the frame appear with its "normal"
size, the second one makes it appear maximized.
Thank you, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Wed, 09 Sep 2020 16:49:01 GMT)
Full text and
rfc822 format available.
Message #128 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On Wed, Sep 9, 2020 at 10:44 AM martin rudalics <rudalics <at> gmx.at> wrote:
> [...]
> Can you please run under gdb [...]
As I said a couple of days ago, I don't have currently a build/debug
environment for Emacs, sorry.
Anyway, I think the problem is very easily reproducible, isn't it?
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Wed, 09 Sep 2020 18:20:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On 9/9/2020 4:44 AM, martin rudalics wrote:
> > I've just downloaded a native w32 build [1] and I've run it on my
> > system (MS Windows 10 Enterprise). I see the same problem with this
> > native build.
>
> Can you please run under gdb with a breakpoint in w32fullscreen_hook of
> w32term.c suitably in here
>
> else if (f->want_fullscreen == FULLSCREEN_MAXIMIZED)
> {
> if (prev_fsmode == FULLSCREEN_BOTH || prev_fsmode == FULLSCREEN_WIDTH
> || prev_fsmode == FULLSCREEN_HEIGHT)
> /* Make window normal since otherwise the subsequent
> maximization might fail in some cases. */
> ShowWindow (hwnd, SW_SHOWNORMAL);
> ShowWindow (hwnd, SW_MAXIMIZE);
> }
>
> and tell us how the frame appears immediately after the ShowWindow
> calls. Here the first call makes the frame appear with its "normal"
> size, the second one makes it appear maximized.
I just tried this on a Cygwin-w32 build from the master branch. I put the
taskbar on the left, started emacs, maximized it, attached gdb, put breakpoints
at each of the ShowWindow lines, and ran through Dani's recipe for producing the
bug. The breakpoints were never hit.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Wed, 09 Sep 2020 20:25:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On 9/9/2020 2:19 PM, Ken Brown wrote:
> On 9/9/2020 4:44 AM, martin rudalics wrote:
>> > I've just downloaded a native w32 build [1] and I've run it on my
>> > system (MS Windows 10 Enterprise). I see the same problem with this
>> > native build.
>>
>> Can you please run under gdb with a breakpoint in w32fullscreen_hook of
>> w32term.c suitably in here
>>
>> else if (f->want_fullscreen == FULLSCREEN_MAXIMIZED)
>> {
>> if (prev_fsmode == FULLSCREEN_BOTH || prev_fsmode == FULLSCREEN_WIDTH
>> || prev_fsmode == FULLSCREEN_HEIGHT)
>> /* Make window normal since otherwise the subsequent
>> maximization might fail in some cases. */
>> ShowWindow (hwnd, SW_SHOWNORMAL);
>> ShowWindow (hwnd, SW_MAXIMIZE);
>> }
>>
>> and tell us how the frame appears immediately after the ShowWindow
>> calls. Here the first call makes the frame appear with its "normal"
>> size, the second one makes it appear maximized.
>
> I just tried this on a Cygwin-w32 build from the master branch. I put the
> taskbar on the left, started emacs, maximized it, attached gdb, put breakpoints
> at each of the ShowWindow lines, and ran through Dani's recipe for producing the
> bug. The breakpoints were never hit.
I just tried again, but this time with a breakpoint at w32fullscreen_hook so
that I could follow the flow. Here are the relevant excerpts from the gdb session:
$ gdb ./emacs
GNU gdb (GDB) (Cygwin 9.2-1) 9.2
[...]
(gdb) b w32fullscreen_hook
Breakpoint 2 at 0x10069507a: file ../../master/src/w32term.c, line 6441.
(gdb) r -Q
Starting program: /home/kbrown/src/emacs/x86_64-w32/src/emacs -Q
[...]
[Press F11]
Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
at ../../master/src/w32term.c:6441
6441 if (FRAME_VISIBLE_P (f))
(gdb) n
6443 HWND hwnd = FRAME_W32_WINDOW(f);
(gdb)
6444 DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
(gdb)
6446 enum fullscreen_type prev_fsmode = FRAME_PREV_FSMODE (f);
(gdb)
6448 block_input();
(gdb)
6449 f->want_fullscreen &= ~FULLSCREEN_WAIT;
(gdb)
6451 if (FRAME_PREV_FSMODE (f) == FULLSCREEN_NONE)
(gdb)
6452 GetWindowPlacement (hwnd, &FRAME_NORMAL_PLACEMENT (f));
(gdb)
6454 if (FRAME_PREV_FSMODE (f) == FULLSCREEN_BOTH)
(gdb)
6460 else if (FRAME_PREV_FSMODE (f) == FULLSCREEN_HEIGHT
(gdb)
6461 || FRAME_PREV_FSMODE (f) == FULLSCREEN_WIDTH)
(gdb)
6464 FRAME_PREV_FSMODE (f) = f->want_fullscreen;
(gdb) p f->want_fullscreen
$1 = FULLSCREEN_BOTH
(gdb) n
6466 if (f->want_fullscreen == FULLSCREEN_NONE)
(gdb)
6468 else if (f->want_fullscreen == FULLSCREEN_MAXIMIZED)
(gdb)
6477 else if (f->want_fullscreen == FULLSCREEN_BOTH)
(gdb)
6479 int menu_bar_height = GetSystemMetrics (SM_CYMENU);
(gdb)
6482 FRAME_NORMAL_PLACEMENT
(f).rcNormalPosition, &rect);
(gdb)
6481 w32_fullscreen_rect (hwnd, f->want_fullscreen,
(gdb)
6483 if (!FRAME_UNDECORATED (f))
(gdb)
6484 SetWindowLong (hwnd, GWL_STYLE, dwStyle & ~WS_OVERLAPPEDWINDOW);
(gdb)
6486 rect.right - rect.left, rect.bottom - rect.top,
(gdb)
6485 SetWindowPos (hwnd, HWND_TOP, rect.left, rect.top,
(gdb)
6486 rect.right - rect.left, rect.bottom - rect.top,
(gdb)
6485 SetWindowPos (hwnd, HWND_TOP, rect.left, rect.top,
(gdb)
6490 FRAME_PIXEL_TO_TEXT_HEIGHT (f, (rect.bottom - rect.top
(gdb)
6488 change_frame_size
(gdb)
6489 (f, FRAME_PIXEL_TO_TEXT_WIDTH (f, rect.right - rect.left),
(gdb)
6488 change_frame_size
(gdb)
6526 f->want_fullscreen = FULLSCREEN_NONE;
(gdb)
6527 unblock_input ();
(gdb)
6529 if (f->want_fullscreen == FULLSCREEN_BOTH
(gdb)
6530 || f->want_fullscreen == FULLSCREEN_WIDTH
(gdb)
6531 || f->want_fullscreen == FULLSCREEN_HEIGHT)
(gdb)
6537 }
[...]
(gdb) c
Continuing.
[Press F11 again]
Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
at ../../master/src/w32term.c:6441
6441 if (FRAME_VISIBLE_P (f))
(gdb) n
6443 HWND hwnd = FRAME_W32_WINDOW(f);
(gdb)
6444 DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
(gdb)
6446 enum fullscreen_type prev_fsmode = FRAME_PREV_FSMODE (f);
(gdb)
6448 block_input();
(gdb)
6449 f->want_fullscreen &= ~FULLSCREEN_WAIT;
(gdb)
6451 if (FRAME_PREV_FSMODE (f) == FULLSCREEN_NONE)
(gdb) p f->want_fullscreen
$2 = FULLSCREEN_NONE
(gdb) n
6454 if (FRAME_PREV_FSMODE (f) == FULLSCREEN_BOTH)
(gdb)
6456 if (!FRAME_UNDECORATED (f))
(gdb)
6457 SetWindowLong (hwnd, GWL_STYLE, dwStyle | WS_OVERLAPPEDWINDOW);
(gdb)
6458 SetWindowPlacement (hwnd, &FRAME_NORMAL_PLACEMENT (f));
(gdb)
6464 FRAME_PREV_FSMODE (f) = f->want_fullscreen;
(gdb)
6466 if (f->want_fullscreen == FULLSCREEN_NONE)
(gdb)
6467 ShowWindow (hwnd, SW_SHOWNORMAL);
[Now the frame reverts to an unmaximized state, exhibiting the bug.]
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 10 Sep 2020 07:17:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 25542 <at> debbugs.gnu.org (full text, mbox):
>> I just tried this on a Cygwin-w32 build from the master branch. I put the taskbar on the left, started emacs, maximized it, attached gdb, put breakpoints at each of the ShowWindow lines, and ran through Dani's recipe for producing the bug. The breakpoints were never hit.
>
> I just tried again, but this time with a breakpoint at w32fullscreen_hook so that I could follow the flow. Here are the relevant excerpts from the gdb session:
Thank you very much for checking.
> Breakpoint 2 at 0x10069507a: file ../../master/src/w32term.c, line 6441.
> (gdb) r -Q
> Starting program: /home/kbrown/src/emacs/x86_64-w32/src/emacs -Q
>
> [...]
>
> [Press F11]
>
> Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
> at ../../master/src/w32term.c:6441
[...]
> 6464 FRAME_PREV_FSMODE (f) = f->want_fullscreen;
> (gdb) p f->want_fullscreen
> $1 = FULLSCREEN_BOTH
While this is the expected value ...
> [...]
>
> (gdb) c
> Continuing.
>
> [Press F11 again]
>
> Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
> at ../../master/src/w32term.c:6441
[...]
> 6451 if (FRAME_PREV_FSMODE (f) == FULLSCREEN_NONE)
> (gdb) p f->want_fullscreen
> $2 = FULLSCREEN_NONE
... the value I would have expected here is FULLSCREEN_MAXIMIZED.
Something must have got broken before. Can you please
(1) Verify that the
f->want_fullscreen &= ~FULLSCREEN_WAIT;
does not interfere in any respect. That is, does f->want_fullscreen
have the same value FULLSCREEN_NONE before anding it with
FULLSCREEN_WAIT?
(2) Does 'toggle-frame-fullscreen' the second time when you type F11
correctly call
(set-frame-parameter frame 'fullscreen fullscreen-restore)
with 'fullscreen-restore' equal to 'maximized' at all?
(3) Verify that calling w32fullscreen_hook with the taskbar on the
bottom does hit the breakpoints and subsequently maximize the frame
as expected.
Thanks again, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 10 Sep 2020 15:06:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On 9/10/2020 3:16 AM, martin rudalics wrote:
> >> I just tried this on a Cygwin-w32 build from the master branch. I put the
> taskbar on the left, started emacs, maximized it, attached gdb, put breakpoints
> at each of the ShowWindow lines, and ran through Dani's recipe for producing the
> bug. The breakpoints were never hit.
> >
> > I just tried again, but this time with a breakpoint at w32fullscreen_hook so
> that I could follow the flow. Here are the relevant excerpts from the gdb session:
>
> Thank you very much for checking.
>
> > Breakpoint 2 at 0x10069507a: file ../../master/src/w32term.c, line 6441.
> > (gdb) r -Q
> > Starting program: /home/kbrown/src/emacs/x86_64-w32/src/emacs -Q
> >
> > [...]
> >
> > [Press F11]
> >
> > Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
> > at ../../master/src/w32term.c:6441
> [...]
> > 6464 FRAME_PREV_FSMODE (f) = f->want_fullscreen;
> > (gdb) p f->want_fullscreen
> > $1 = FULLSCREEN_BOTH
>
> While this is the expected value ...
>
> > [...]
> >
> > (gdb) c
> > Continuing.
> >
> > [Press F11 again]
> >
> > Thread 1 "emacs" hit Breakpoint 2, w32fullscreen_hook (f=0x8001f7c88)
> > at ../../master/src/w32term.c:6441
> [...]
> > 6451 if (FRAME_PREV_FSMODE (f) == FULLSCREEN_NONE)
> > (gdb) p f->want_fullscreen
> > $2 = FULLSCREEN_NONE
>
> ... the value I would have expected here is FULLSCREEN_MAXIMIZED.
> Something must have got broken before. Can you please
>
> (1) Verify that the
>
> f->want_fullscreen &= ~FULLSCREEN_WAIT;
>
> does not interfere in any respect. That is, does f->want_fullscreen
> have the same value FULLSCREEN_NONE before anding it with
> FULLSCREEN_WAIT?
Yes.
> (2) Does 'toggle-frame-fullscreen' the second time when you type F11
> correctly call
>
> (set-frame-parameter frame 'fullscreen fullscreen-restore)
>
> with 'fullscreen-restore' equal to 'maximized' at all?
No. The value of 'fullscreen-restore' is nil. But if I repeat the experiment
with the taskbar on the bottom, the value of fullscreen-restore is 'maximized'.
> (3) Verify that calling w32fullscreen_hook with the taskbar on the
> bottom does hit the breakpoints and subsequently maximize the frame
> as expected.
With the taskbar on the bottom, f->want_fullscreen == FULLSCREEN_MAXIMIZED when
I hit line 6449 after the second F11, and everything goes as expected after that.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 10 Sep 2020 18:17:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 25542 <at> debbugs.gnu.org (full text, mbox):
>> (2) Does 'toggle-frame-fullscreen' the second time when you type F11
>> correctly call
>>
>> (set-frame-parameter frame 'fullscreen fullscreen-restore)
>>
>> with 'fullscreen-restore' equal to 'maximized' at all?
>
> No. The value of 'fullscreen-restore' is nil. But if I repeat the experiment with the taskbar on the bottom, the value of fullscreen-restore is 'maximized'.
Thanks for telling me what I forgot to ask. IIUC this means that after
maximizing the frame with the mouse, the value of
(frame-parameter nil 'fullscreen)
is nil. Correct? And what is its value if, instead, you maximize the
frame via 'toggle-frame-maximized'?
In either case the bug should be a consequence of the earlier mentioned
if (x < 0 && y < 0)
store_frame_param (f, Qfullscreen, Qmaximized);
so we do not remember in the fullscreen parameter that the frame has
been maximized. Apparently some check _is_ needed (why?) so probably
using
if (x < 0 || y < 0)
store_frame_param (f, Qfullscreen, Qmaximized);
instead will fix it. Can you try that (as I said elsewhere it will then
fail for borderless, maximized frames)?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Thu, 10 Sep 2020 19:05:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On 9/10/2020 2:16 PM, martin rudalics wrote:
> >> (2) Does 'toggle-frame-fullscreen' the second time when you type F11
> >> correctly call
> >>
> >> (set-frame-parameter frame 'fullscreen fullscreen-restore)
> >>
> >> with 'fullscreen-restore' equal to 'maximized' at all?
> >
> > No. The value of 'fullscreen-restore' is nil. But if I repeat the
> experiment with the taskbar on the bottom, the value of fullscreen-restore is
> 'maximized'.
>
> Thanks for telling me what I forgot to ask. IIUC this means that after
> maximizing the frame with the mouse, the value of
>
> (frame-parameter nil 'fullscreen)
>
> is nil. Correct?
Yes.
> And what is its value if, instead, you maximize the
> frame via 'toggle-frame-maximized'?
maximized.
> In either case the bug should be a consequence of the earlier mentioned
>
> if (x < 0 && y < 0)
> store_frame_param (f, Qfullscreen, Qmaximized);
>
> so we do not remember in the fullscreen parameter that the frame has
> been maximized. Apparently some check _is_ needed (why?) so probably
> using
>
> if (x < 0 || y < 0)
> store_frame_param (f, Qfullscreen, Qmaximized);
>
> instead will fix it. Can you try that (as I said elsewhere it will then
> fail for borderless, maximized frames)?
Yes, that does fix it. I haven't tried to test anything involving borderless
frames.
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 11 Sep 2020 12:32:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 25542 <at> debbugs.gnu.org (full text, mbox):
>> ... after
>> maximizing the frame with the mouse, the value of
>>
>> (frame-parameter nil 'fullscreen)
>>
>> is nil. Correct?
>
> Yes.
>
>> And what is its value if, instead, you maximize the
>> frame via 'toggle-frame-maximized'?
>
> maximized.
Mixing frame resizing triggered by Emacs commands and external tools is
tricky to handle.
>> Apparently some check _is_ needed (why?) so probably
>> using
>>
>> if (x < 0 || y < 0)
>> store_frame_param (f, Qfullscreen, Qmaximized);
>>
>> instead will fix it. Can you try that (as I said elsewhere it will then
>> fail for borderless, maximized frames)?
>
> Yes, that does fix it.
So we'll probably have to use that. Can you install it?
> I haven't tried to test anything involving borderless frames.
If you
(set-frame-parameter nil 'undecorated t)
and maximize the frame via some Windows (Aero, IIRC) command, what does
(frame-parameter nil 'fullscreen)
report? With and without the && ~> || change.
And it would still be interesting to understand your earlier finding,
namely that
If I make this change and follow Dani's recipe from the original bug
report, the second F11 press doesn't restore the previous state.
Instead, the frame appears to get slightly smaller for an instant and
then immediately reverts to fullscreen mode.
That second F11 should set the 'fullscreen parameter to 'maximized so I
fail to see how a subsequent action can restore it to 'fullboth. In
retrospect, that
/* Windows can send us a SIZE_MAXIMIZED message even
when fullscreen is fullboth ....
comment apparently matches your experience now but I cannot even recall
based on what experience I added it back then.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 11 Sep 2020 20:17:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 25542 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 9/11/2020 3:53 AM, martin rudalics wrote:
> >> ... after
> >> maximizing the frame with the mouse, the value of
> >>
> >> (frame-parameter nil 'fullscreen)
> >>
> >> is nil. Correct?
> >
> > Yes.
> >
> >> And what is its value if, instead, you maximize the
> >> frame via 'toggle-frame-maximized'?
> >
> > maximized.
>
> Mixing frame resizing triggered by Emacs commands and external tools is
> tricky to handle.
>
> >> Apparently some check _is_ needed (why?) so probably
> >> using
> >>
> >> if (x < 0 || y < 0)
> >> store_frame_param (f, Qfullscreen, Qmaximized);
> >>
> >> instead will fix it. Can you try that (as I said elsewhere it will then
> >> fail for borderless, maximized frames)?
> >
> > Yes, that does fix it.
>
> So we'll probably have to use that. Can you install it?
Patch attached (under your name). Please check it and see if the commit message
and comment change are OK.
Eli and Lars, I think this should go to master rather than the emacs-27 branch,
since there's too much that we don't understand about the fix. Do you agree?
> > I haven't tried to test anything involving borderless frames.
>
> If you
>
> (set-frame-parameter nil 'undecorated t)
>
> and maximize the frame via some Windows (Aero, IIRC) command, what does
Sorry, but I don't know what an Aero command is, and I'm not interested in
learning if I don't have to. If anyone really cares about this case and can't
carry out the experiment themselves, I'm willing to do it, but I'll need
explicit instructions.
> (frame-parameter nil 'fullscreen)
>
> report? With and without the && ~> || change.
>
> And it would still be interesting to understand your earlier finding,
> namely that
>
> If I make this change and follow Dani's recipe from the original bug
> report, the second F11 press doesn't restore the previous state.
> Instead, the frame appears to get slightly smaller for an instant and
> then immediately reverts to fullscreen mode.
>
> That second F11 should set the 'fullscreen parameter to 'maximized so I
> fail to see how a subsequent action can restore it to 'fullboth. In
> retrospect, that
>
> /* Windows can send us a SIZE_MAXIMIZED message even
> when fullscreen is fullboth ....
>
> comment apparently matches your experience now but I cannot even recall
> based on what experience I added it back then.
>
> Thanks, martin
Ken
[0001-Fix-toggle-frame-fullscreen-on-w32-builds.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 11 Sep 2020 20:34:02 GMT)
Full text and
rfc822 format available.
Message #155 received at submit <at> debbugs.gnu.org (full text, mbox):
Ken Brown writes:
>> If you
>> (set-frame-parameter nil 'undecorated t)
>> and maximize the frame via some Windows (Aero, IIRC) command, what
>> does
>
> Sorry, but I don't know what an Aero command is, and I'm not
> interested in learning if I don't have to. If anyone really cares
> about this case and can't carry out the experiment themselves, I'm
> willing to do it, but I'll need explicit instructions.
I think he's referring to the Win+Up shortcut, which maximizes the frame
on the current screen.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Fri, 11 Sep 2020 21:20:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 25542 <at> debbugs.gnu.org (full text, mbox):
On 9/11/2020 4:33 PM, Achim Gratz wrote:
> Ken Brown writes:
>>> If you
>>> (set-frame-parameter nil 'undecorated t)
>>> and maximize the frame via some Windows (Aero, IIRC) command, what
>>> does
>>
>> Sorry, but I don't know what an Aero command is, and I'm not
>> interested in learning if I don't have to. If anyone really cares
>> about this case and can't carry out the experiment themselves, I'm
>> willing to do it, but I'll need explicit instructions.
>
> I think he's referring to the Win+Up shortcut, which maximizes the frame
> on the current screen.
Thanks, I didn't know about that. Martin, is that what you meant? Do you want
me to play with that and answer your questions before installing the other patch?
Ken
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 12 Sep 2020 06:07:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 25542 <at> debbugs.gnu.org,
> Noam Postavsky <npostavs <at> users.sourceforge.net>
> From: Ken Brown <kbrown <at> cornell.edu>
> Date: Fri, 11 Sep 2020 16:16:09 -0400
>
> Patch attached (under your name). Please check it and see if the commit message
> and comment change are OK.
>
> Eli and Lars, I think this should go to master rather than the emacs-27 branch,
> since there's too much that we don't understand about the fix. Do you agree?
Yes, I definitely agree: the use case is rare and the fix is not
self-evident.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 12 Sep 2020 06:55:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> Patch attached (under your name). Please check it and see if the commit message and comment change are OK.
Looks perfect to me.
Many thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 12 Sep 2020 06:55:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> I think he's referring to the Win+Up shortcut, which maximizes the frame
> on the current screen.
Right. Wasn't that part of something they called Aero on Windows 7?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25542; Package
emacs.
(Sat, 12 Sep 2020 06:56:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 25542 <at> debbugs.gnu.org (full text, mbox):
> Thanks, I didn't know about that. Martin, is that what you meant? Do you want me to play with that and answer your questions before installing the other patch?
No. Please go ahead and install the patch. Maybe, as soon as I can
build master again, I'll play around with this myself.
martin
Reply sent
to
Ken Brown <kbrown <at> cornell.edu>:
You have taken responsibility.
(Sat, 12 Sep 2020 11:38:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Dani Moncayo <dmoncayo <at> gmail.com>:
bug acknowledged by developer.
(Sat, 12 Sep 2020 11:38:02 GMT)
Full text and
rfc822 format available.
Message #175 received at 25542-done <at> debbugs.gnu.org (full text, mbox):
On 9/12/2020 2:54 AM, martin rudalics wrote:
> > Thanks, I didn't know about that. Martin, is that what you meant? Do you
> want me to play with that and answer your questions before installing the other
> patch?
>
> No. Please go ahead and install the patch. Maybe, as soon as I can
> build master again, I'll play around with this myself.
Done. Closing.
Ken
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 11 Oct 2020 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 257 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.