GNU bug report logs - #65840
29.1; desktop-load moves frames to the right and down

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Christian Tanzer <tanzer <at> gg32.com>
Cc: 65840 <at> debbugs.gnu.org
Subject: bug#65840: 29.1; desktop-load moves frames to the right and down
Date: Sat, 09 Sep 2023 17:47:37 +0300

[Please use Reply All to reply, to keep the bug tracker CC'ed.]

> From: Christian Tanzer <tanzer <at> gg32.com>
> Date: Sat, 9 Sep 2023 14:47:34 +0100
> 
> On 09.09.2023, at 13:59, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> >> Date: Sat, 09 Sep 2023 12:32:42 -0000
> >> From: tanzer--- via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >> 
> >> In GNU Emacs 29.1, desktop-load moves frames to the right and down.
> > 
> > This is probably specific to macOS, or maybe even to your window
> > manager, because it doesn't happen to me, and I'm a heavy user of
> > desktop.el.
> 
> I am using plain macOS without any additional window manager.
> 
> > When you say "In GNU Emacs 29.1", do you mean this issue is specific
> > to Emacs 29.1, and does not happen with Emacs 28 and older?
> 
> It doesn’t happen on 28.2 or older. 

So it could be due to massive changes in the macOS display code we did
in Emacs 29.

> 
> >> The three attachements show the shifts in frame positions:
> >> 
> >> - .emacs.desktop.1 contains the correct frame positions after using
> >>  `desktop-save` and copying .emacs.desktop to .emacs.desktop.1
> >> 
> >> - Loading .emacs.desktop.1 into Emacs 29 results in the frames being
> >>  shifted. On exiting Emacs 29, the shifted positions are stored in
> >>  .emacs.desktop and copied to .emacs.desktop.2.
> >> 
> >> - Loading .emacs.desktop.2 into Emacs 29 results in the frames being
> >>  shifted again. On exiting Emacs 29, the shifted positions are stored
> >>  in .emacs.desktop and copied to .emacs.desktop.3.
> >> 
> >> - Loading any of these .emacs.desktop files into Emacs 28.2 results in
> >>  the expected frame positions (in case of .2 and .3 the positions
> >>  incorrectly shifted to by Emacs 29).
> > 
> > You are aware, I hope, that on X and similar GUI systems, the
> > coordinates of the frames we request from the window-manager are
> > advisory: the WM doesn't have to adhere to what we request.  I'm not
> > sure what you see is not a manifestation of that.
> 
> I am aware of that but there is a clear regression here. 
> 
> Loading the same .emacs.desktop in 28.2 works as expected while in 29.1 all frames are shifted (one of my test frames first to behind the dock and then partly outside the visible screen). In 29.1, each load/save cycle of the .emacs.desktop will shift all the frames a bit farther right and down. 
> 
> If the WM was the real culprit I would expect the version of Emacs to be irrelevant!
> 
> For me, the desktop machinery started getting flaky with Emacs 28.1 which crashes when reading larger desktop files written by Emacs 27. Emacs 29.1 still shows that behavior. Unfortunately I have not been able to find a small reproducible test case for these crashes.
> 
> Both 28.2 and 29.1 work with a smaller desktop file that I created with 29.1 but then I noticed the frames being shifted by each restart of 29.1, which 28.2 doesn’t do.
> 
> I don’t want to be stuck with Emacs 27 and I am getting nervous about the desktop problems of 28 and 29.

Hopefully, the advice posted by Po Lu could lead us to understanding
the problem.

Previous Next

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