GNU bug report logs -
#16340
24.3.50; Maximize to the left/right side of the screen (on Windows 7 & 8)
Previous Next
Reported by: Dani Moncayo <dmoncayo <at> gmail.com>
Date: Sat, 4 Jan 2014 18:59:02 UTC
Severity: minor
Found in version 24.3.50
Done: Dani Moncayo <dmoncayo <at> gmail.com>
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 16340 in the body.
You can then email your comments to 16340 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#16340
; Package
emacs
.
(Sat, 04 Jan 2014 18:59: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
.
(Sat, 04 Jan 2014 18:59:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Severity: minor
On my Windows 8 system, the "maximize to the left/right" feature of
the OS is not working quite well with Emacs (-Q). See these
screenshots:
https://drive.google.com/folderview?id=0B92qXLRvF4ziLUdQNTVFYUFXQm8&usp=sharing
As you can see:
1. When Emacs is maximized to the left ("windows key" + "left arrow"),
there is some residual space at the left and top edges of the Emacs
frame. There should be no such space. Compare "emacs-left" (wrong)
with "chrome-left" (ok).
2. When Emacs is maximized to the right ("windows key" + "right
arrow"), there is some residual space at the top edge of the Emacs
frame. Compare "emacs-right" (wrong) with "chrome-right" (ok).
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2014-01-04 on LEG570
Bzr revision: 115865 rudalics <at> gmx.at-20140104093130-ccgmn1edhogzfv7l
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
`configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Sun, 05 Jan 2014 10:38:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> On my Windows 8 system, the "maximize to the left/right" feature of
> the OS is not working quite well with Emacs (-Q). See these
> screenshots:
>
> https://drive.google.com/folderview?id=0B92qXLRvF4ziLUdQNTVFYUFXQm8&usp=sharing
>
> As you can see:
>
> 1. When Emacs is maximized to the left ("windows key" + "left arrow"),
> there is some residual space at the left and top edges of the Emacs
> frame. There should be no such space. Compare "emacs-left" (wrong)
> with "chrome-left" (ok).
>
> 2. When Emacs is maximized to the right ("windows key" + "right
> arrow"), there is some residual space at the top edge of the Emacs
> frame. Compare "emacs-right" (wrong) with "chrome-right" (ok).
If I interpret your caps correctly, the space is created by Windows
itself which tries to obey Emacs' size hints. Emacs wouldn't adjust the
frame to the right-bottom edge. Can you try with
`frame-resize-pixelwise' non-nil (either in your .emacs or before
creating a new frame that you want to maximize to the left).
And please tell me the values of (frame-parameter nil 'fullscreen)
before, during and after you left the "maximized to the left" state. I
need them to investigate Juanma's scenario.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Mon, 06 Jan 2014 19:35:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> Can you try with
> `frame-resize-pixelwise' non-nil (either in your .emacs or before
> creating a new frame that you want to maximize to the left).
Ok: the new frame I create after setting 'frame-resize-pixelwise' to
't' doesn't have the problem reported in this bug, i.e. that frame
fits exactly in the left/right half of the screen when I do "windows
key" + "left/right arrow".
> And please tell me the values of (frame-parameter nil 'fullscreen)
> before, during and after you left the "maximized to the left" state.
'(frame-parameter nil 'fullscreen)' returns 'nil' before, during and
after the "maximization to the left".
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Mon, 06 Jan 2014 19:59:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> Ok: the new frame I create after setting 'frame-resize-pixelwise' to
> 't' doesn't have the problem reported in this bug, i.e. that frame
> fits exactly in the left/right half of the screen when I do "windows
> key" + "left/right arrow".
So all I can say is that Windows obeys your size hints. If you can live
with pixelwise resized frames (I do so for almost a year now) continue
to do so. Otherwise you have to live with the gaps. Tertium non datur.
>> And please tell me the values of (frame-parameter nil 'fullscreen)
>> before, during and after you left the "maximized to the left" state.
>
> '(frame-parameter nil 'fullscreen)' returns 'nil' before, during and
> after the "maximization to the left".
Thanks. This confirms what Juanma told me earlier.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Mon, 06 Jan 2014 20:57:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 16340 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jan 6, 2014 at 8:58 PM, martin rudalics <rudalics <at> gmx.at> wrote:
>> Ok: the new frame I create after setting 'frame-resize-pixelwise' to
>> 't' doesn't have the problem reported in this bug, i.e. that frame
>> fits exactly in the left/right half of the screen when I do "windows
>> key" + "left/right arrow".
>
> So all I can say is that Windows obeys your size hints. If you can live
> with pixelwise resized frames (I do so for almost a year now) continue
> to do so. Otherwise you have to live with the gaps. Tertium non datur.
I can live with the gaps, certainly, but I still think that the right
behavior would be not to have those gaps, obviously.
That's my opinion, but mark this bug as "wontfix" and close it if you
want. I will not complain. I wanted to report a minor misbehavior I
spotted while playing around; just that.
Thank you.
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Mon, 06 Jan 2014 22:04:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> I can live with the gaps, certainly, but I still think that the right
> behavior would be not to have those gaps, obviously.
If you don't want the gaps, you have to set `frame-resize-pixelwise' to
true. That's what all other graphical programs on Windows do and that's
what I do. And that also means that dragging the border of an Emacs
frame will resize it pixelwise like the window of any other graphical
application.
> That's my opinion, but mark this bug as "wontfix" and close it if you
> want. I will not complain. I wanted to report a minor misbehavior I
> spotted while playing around; just that.
It is fixed by setting `frame-resize-pixelwise' to t. So "wontfix"
won't apply ;-)
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Mon, 06 Jan 2014 22:17:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> If you don't want the gaps, you have to set `frame-resize-pixelwise' to
> true. That's what all other graphical programs on Windows do and that's
> what I do. And that also means that dragging the border of an Emacs
> frame will resize it pixelwise like the window of any other graphical
> application.
But with 'frame-resize-pixelwise' set to 'nil', a maximized Emacs
frame takes up the whole "available" screen (except the taskbar),
without letting any gaps anywhere. That's why I expected "maximize to
left/right" to also take the whole left/right half of the available
screen (without gaps).
But I think that the key difference, which I didn't understand until
now, may be that "maximize to left/right" (unlike the standard
"maximize") aren't "states" of a window, i.e. the OS simply tries to
resize and relocate the window to occupy the corresponding half of the
screen. In that case, I understand the behavior I see, and I agree it
is not a bug.
I'll close this bug report then.
Thanks for your time.
--
Dani Moncayo
bug closed, send any further explanations to
16340 <at> debbugs.gnu.org and Dani Moncayo <dmoncayo <at> gmail.com>
Request was from
Dani Moncayo <dmoncayo <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 06 Jan 2014 22:18:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Mon, 06 Jan 2014 23:06:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 16340 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jan 6, 2014 at 11:16 PM, Dani Moncayo <dmoncayo <at> gmail.com> wrote:
> "maximize to left/right" (unlike the standard
> "maximize") aren't "states" of a window, i.e. the OS simply tries to
> resize and relocate the window to occupy the corresponding half of the
> screen.
That's not really true, or at least, is not all the truth. Open
Notepad, grab it by the caption, and move it to the left or right;
Windows will "maximize it" to half-display left or right. Then grab it
again from the caption, and move it off the side of the display:
Windows restores its previous size. So the half-maximized left/right
is some sort of state of a window, it's not just a resizing, because
on a normal resizing Windows does not remember the previous dimensions
of the window. Vertical maximization (Win+Shift+Up) is also a
"sort-of-maximized" state that can be restored with Win+Shift-Down.
J
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Tue, 07 Jan 2014 01:12:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 16340 <at> debbugs.gnu.org (full text, mbox):
On 01/06/2014 02:03 PM, martin rudalics wrote:
> > I can live with the gaps, certainly, but I still think that the right
> > behavior would be not to have those gaps, obviously.
>
> If you don't want the gaps, you have to set `frame-resize-pixelwise' to
> true. That's what all other graphical programs on Windows do and that's
> what I do. And that also means that dragging the border of an Emacs
> frame will resize it pixelwise like the window of any other graphical
> application.
>
> > That's my opinion, but mark this bug as "wontfix" and close it if you
> > want. I will not complain. I wanted to report a minor misbehavior I
> > spotted while playing around; just that.
>
> It is fixed by setting `frame-resize-pixelwise' to t. So "wontfix"
> won't apply ;-)
By the way: M-: (setq frame-resize-pixelwise t) seems to affect new
frames, but not the current one. Is that expected behavior?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Tue, 07 Jan 2014 07:09:03 GMT)
Full text and
rfc822 format available.
Message #34 received at 16340 <at> debbugs.gnu.org (full text, mbox):
>> "maximize to left/right" (unlike the standard
>> "maximize") aren't "states" of a window, i.e. the OS simply tries to
>> resize and relocate the window to occupy the corresponding half of the
>> screen.
>
> That's not really true, or at least, is not all the truth. Open
> Notepad, grab it by the caption, and move it to the left or right;
> Windows will "maximize it" to half-display left or right. Then grab it
> again from the caption, and move it off the side of the display:
> Windows restores its previous size. So the half-maximized left/right
> is some sort of state of a window, it's not just a resizing, because
> on a normal resizing Windows does not remember the previous dimensions
> of the window. Vertical maximization (Win+Shift+Up) is also a
> "sort-of-maximized" state that can be restored with Win+Shift-Down.
Duh, you're right Juanma. (I should have deferred my reply to Martin
until after sleeping :).)
Therefore, I think that the questions now are: if these ("maximized to
left/right") are special states of a window, could Emacs keep track of
them? And if so, could Emacs DTRT (i.e. avoid the gaps) when they are
active?
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Tue, 07 Jan 2014 10:20:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> But with 'frame-resize-pixelwise' set to 'nil', a maximized Emacs
> frame takes up the whole "available" screen (except the taskbar),
> without letting any gaps anywhere.
By accident only, I suppose. Some of my Debian builds seem to resist
fully maximizing the frame unless `frame-resize-pixelwise' is set. And
bug#16379 seems to confirm such behavior for Windows as well.
> That's why I expected "maximize to
> left/right" to also take the whole left/right half of the available
> screen (without gaps).
It's the call
GetClientRect (msg.msg.hwnd, &rect);
on line 4718 of w32term.c that counts here. Whatever Windows asks us is
what Emacs processes here. And IIUC (from my experience and what you
told me) Windows sends us non-size-hint-truncated coordinates for a full
maximization request and size-hint-truncated coordinates for a
left/right maximization request.
> But I think that the key difference, which I didn't understand until
> now, may be that "maximize to left/right" (unlike the standard
> "maximize") aren't "states" of a window, i.e. the OS simply tries to
> resize and relocate the window to occupy the corresponding half of the
> screen.
I believe that what we see here is an internal hack of Windows. That
is, internally, the Aero (or what it is called) part of Windows
maintains the left/right maximized state separate. You should be able
to verify this by increasing/removing the taskbar or whatever you have
near the Emacs frame. If the Emacs frame adapts to the change, we know
that Aero/Windows tracks its state. In any case it seems that Windows
does not communicate that state to the application, probably so because
the API doesn't provide the corresponding feature.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Tue, 07 Jan 2014 10:20:03 GMT)
Full text and
rfc822 format available.
Message #40 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> That's not really true, or at least, is not all the truth. Open
> Notepad, grab it by the caption, and move it to the left or right;
> Windows will "maximize it" to half-display left or right. Then grab it
> again from the caption, and move it off the side of the display:
> Windows restores its previous size. So the half-maximized left/right
> is some sort of state of a window, it's not just a resizing, because
> on a normal resizing Windows does not remember the previous dimensions
> of the window. Vertical maximization (Win+Shift+Up) is also a
> "sort-of-maximized" state that can be restored with Win+Shift-Down.
Can/do we trigger that "restore" from emacs?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Tue, 07 Jan 2014 10:20:04 GMT)
Full text and
rfc822 format available.
Message #43 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> By the way: M-: (setq frame-resize-pixelwise t) seems to affect new
> frames, but not the current one. Is that expected behavior?
It should affect the current one as soon as the next size hint request
iss passed to the window manager. We could force that by sending an
explicit x_wm_set_size_hint whenever we set that variable but so far I
have not bothered to do that. Also, I'm not sure either whether we
should make this a frame parameter. Suggestions welcome.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Tue, 07 Jan 2014 10:20:05 GMT)
Full text and
rfc822 format available.
Message #46 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> Therefore, I think that the questions now are: if these ("maximized to
> left/right") are special states of a window, could Emacs keep track of
> them?
I'm afraid the answer is no. But maybe Juanma finds out something about
this.
> And if so, could Emacs DTRT (i.e. avoid the gaps) when they are
> active?
If the API does communicate them to us, yes. But still I think that
setting `frame-resize-pixelwise' to t is much simpler in that case.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Tue, 07 Jan 2014 13:43:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 16340 <at> debbugs.gnu.org (full text, mbox):
On Tue, 07 Jan 2014 11:19:18 +0100 martin rudalics <rudalics <at> gmx.at> wrote:
>> By the way: M-: (setq frame-resize-pixelwise t) seems to affect new
>> frames, but not the current one. Is that expected behavior?
>
> It should affect the current one as soon as the next size hint request
> iss passed to the window manager.
Is there an Emacs command or function that induces such a hint, or any
user manipulation of the current frame? Just dragging the edge of the
frame does not make it resize pixelwise, whereas with a new frame that
works immediately.
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Tue, 07 Jan 2014 17:33:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> Is there an Emacs command or function that induces such a hint,
The intended use of the option is via .emacs. Did you try that?
> or any
> user manipulation of the current frame? Just dragging the edge of the
> frame does not make it resize pixelwise, whereas with a new frame that
> works immediately.
It should work after the first resize operation (at least it does so
here) because that sets the hint. Maybe I should write a function that
allows to set the hints manually at least for the base, minimum, maximum
sizes and the increments. After the release.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Tue, 07 Jan 2014 17:37:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> By the way: M-: (setq frame-resize-pixelwise t) seems to affect new
> frames, but not the current one.
It affects the current one _after_ the first resize operation on it.
> Is that expected behavior?
Yes. This option should be rather used only in .emacs. It expresses a
global preference of the user, should not be bound or set interactively.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Tue, 07 Jan 2014 19:51:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 16340 <at> debbugs.gnu.org (full text, mbox):
On Tue, 07 Jan 2014 18:31:58 +0100 martin rudalics <rudalics <at> gmx.at> wrote:
>> Is there an Emacs command or function that induces such a hint,
>
> The intended use of the option is via .emacs. Did you try that?
I just did, and it does indeed work as you say. Shouldn't the doc
string of frame-resize-pixelwise say it must be set in the user's init
file to affect the initial frame?
Steve Berman
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16340
; Package
emacs
.
(Sat, 11 Jan 2014 10:25:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 16340 <at> debbugs.gnu.org (full text, mbox):
> I just did, and it does indeed work as you say. Shouldn't the doc
> string of frame-resize-pixelwise say it must be set in the user's init
> file to affect the initial frame?
Done in revision 115972.
martin
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 08 Feb 2014 12:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 176 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.