GNU bug report logs - #32977
26.1.50; Emacs (on gnome 3, wayland, debian buster) calculates incorrect horizontal positions

Previous Next

Package: emacs;

Reported by: Kai Tetzlaff <kai.tetzlaff <at> web.de>

Date: Sun, 7 Oct 2018 19:09:02 UTC

Severity: normal

Found in version 26.1.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Kai Tetzlaff <kai.tetzlaff <at> web.de>, 32977 <at> debbugs.gnu.org
Subject: bug#32977: 26.1.50; Emacs (on gnome 3, wayland, debian buster) calculates incorrect horizontal positions
Date: Thu, 26 Nov 2020 15:32:10 +0100
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> (This bug report unfortunately got no response at the time.)
>
> I can reproduce this bug in Emacs 28:
>
> (set-frame-position (selected-frame) 0 0)
> => t
> (frame-position (selected-frame))
> => (-10 . 66)
>
> If I do this, I can clearly see that the frame isn't outside the screen
> (i.e., I can see other windows between the Emacs frame and the border of
> the screen):
>
> (set-frame-position (selected-frame) 9 0)
> => t
>
> But still:
>
> (frame-position (selected-frame))
> => (-1 . 66)
>
> This is a Debian bullseye system with Gnome Shell.
>
> Anybody got an idea what's going on here?

This is under X, right? GTK/GDK's idea of window coordinates and
Emacs's idea sometimes disagree, especially when using Gnome Shell.

The answer is pure gtk, but in the pure gtk branch under Wayland,
frame-position will return (0 . 0) however the frame will not actually
move when you call set-frame-position.

pure gtk under X moves the frame, *and* returns (0 . 0), so I guess
this should be filed as a bug against the pure gtk branch.

Robert




This bug report was last modified 4 years and 233 days ago.

Previous Next


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