GNU bug report logs - #24298
25.1; problem with restoring desktop

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: covici <at> ccs.covici.com
Cc: 24298 <at> debbugs.gnu.org
Subject: bug#24298: Acknowledgement (25.1; problem with restoring desktop)
Date: Sat, 10 Dec 2016 17:50:05 +0200

> Date: Sat, 10 Dec 2016 10:02:11 -0500
> From: John Covici <covici <at> ccs.covici.com>
> Cc: 24298 <at> debbugs.gnu.org
> 
> I can reproduce this with a  desktop with just two buffers, what
> happens is when the commit is there, the wrong buffer is the current
> one and  if I do c-x-b it has the scratch buffer as the next one
> rather than the previous buffer.  For instance in the desktop I will
> send you, the current buffer is the Makefile, but when I restore the
> desktop, default.xml is made the current buffer instead and the
> scratch buffer is the default for c-x-b.

The desktop file you sent doesn't have Makefile, it has default.xml
and brltty-9999.ebuild.  The buffer that's expected to be the current
one after restoring is the first one in the list, and in your case
it's default.xml.  So if that buffer becomes the current after
restoring desktop, I don't see a problem in the restore stage, and
don't understand how that commit could have changed this.

What do you see in the list returned by buffer-list, before you end a
session?  The buffers are recorded in the desktop file in the order
they appear in that list, and in my case, this is the current buffer
when I invoke desktop-save.

Previous Next

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