[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: desktop-restore-frames

From: martin rudalics
Subject: Re: desktop-restore-frames
Date: Mon, 29 Jul 2013 09:54:19 +0200

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]