bug#24298: 25.1; problem with restoring desktop

[N. Jackson]

At 11:16 +0200 on Thursday 2016-08-25, martin rudalics wrote:

>> I might say (half jokingly) that I quite like this new "feature": I
>> get buffers popping up that I was working on six months ago and forgot
>> all about!
>
> At least this part seems hardly related to framesets.  It might be
> related to your desktop file settings.

Hi Martin,

At the risk of further noise but to be sure that I haven't muddied the
waters with my previous post, to be clear:

- These are buffers that have been open in every session since I was
working on them, they just haven't had windows for months (or years).

- When I said they're "popping up" I really ought to have just said that
they're randomly being given windows when Emacs starts.

- (These are in GUI frames on GNU/Linux.)

I understood this to be the complaint of the OP which I understood Eli
to have said he doesn't see:

At 07:31 -0400 on Wednesday 2016-08-24, John Covici wrote:

> I am having a problem restoring my desktop, when there are several
> buffers. Instead of restoring the correct buffer as the current one, a
> random buffer is restored.

I don't believe I have any settings in this area at all, other than
these two settings in my custom-set-variables:

  '(desktop-path (quote ("." "~/.emacs.d/" "~")))
  '(desktop-save-mode t)

I haven't yet tried your suggestion of setting desktop-restore-frames to
`nil' (it is currently `t') because it's doc string merely says:

  When non-nil, save and restore the frame and window configuration.
  See related options `desktop-restore-reuses-frames',
  `desktop-restore-in-current-display', and `desktop-restore-forces-onscreen'.

This neglects to mention what it does when it's set to `nil'.

N.