Re: desktop-restore-frames

[martin rudalics]

>> - M-x desktop-clear "cleans up" the desktop by removing buffers, etc.
>> Should that command also (directly or via an argument) remove windows
>> and/or frames? IMO both possibilities seem reasonable.
>
> I think the answer is yes, `desktop-clear' should delete frames too.
> The biggest issue to implement this is deciding about exclusions. For
> buffers there's `desktop-clear-preserve-buffers', which selects based
> on the buffer name; a sensible choice. But what is a good way to
> differentiate between frames?

I'd kill all frames but one.  `desktop-clear' means to start from a
pristine state and one minibuffer-equipped frame showing *scratch* is
the best approximation we have.

> Personally, I like doing this with frame
> parameters (over filter functions) for a few reasons:
[...]
> Is anyone opposed to doing things that way?

I agree with you.

> - Making sure that the selected frame at saving time is still selected
> at restore time (assuming the frame was saved, of course).

I suppose we want to make sure the window selected when saving should be
selected after restoring (unless it's a minibuffer window).

> - On insight, I think I could have done all this in a new
> desktop-frames.el package, loaded by default from desktop.el. The
> advantage is that the current code works or could be easily made to
> work on Emacs 24.{1,2,3}, which has window-state-(get|put), so it
> could be added to ELPA as a back-compatible package.

IIUC we'd have to fix a couple of errors in the Emacs sources to make it
work so I would advise against trying to make it backward compatible.

> - With really little effort, it is possible to create a mini-package
> to save & restore a stack or queue of frame configurations
> dynamically, so you could do
>
>   M-x save-frame-state   ; pushes state
>   M-x restore-frame-state   ; pops state
>   C-{N} M-x restore-frame-state  ; restores state {N}, does not pop
>   M-x next-frame-state
>
> etc. so you could, on one session, push, pop and cycle between frame
> states (it could even be made persistent). This does not offer too
> much of an advantage over the current frame-configuration-to-register
> stuff, but offers more flexibility: for example, with a bit of coding
> there could be commands to bring all frames in all displays to the
> current display, or to delete all frames in other displays.

It has the advantage that we can save "something like" registered frame
configurations to disk and read them back.

martin