Re: desktop-restore-frames

[martin rudalics <rudalics@gmx.at>]

 >> - 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