Re: desktop-restore-frames

[Juanma Barranquero]

Not that I received much feedback, but anyway, in case someone wants
to add their thoughts...


> * NOT ADDED / FOR DISCUSSION:
>
> - I have not made any attempt to detect off-screen frames and move
> them back on-screen. As there are legitimate uses of off-screen
> frames, we should discuss what is the expected UI before throwing code
> at it.

This is now implemented via a new option
`desktop-restore-forces-onscreen', with three possibilities:

 - t means to force back onscreen any restored frame not visible at
all in its display.
 - 'all means the same, but includes frames partially visible.
 - nil means do nothing.

defaulting to t. Of course, checking whether a frame is offscreen or
not is a bit fuzzy because of the impossibility of getting a precise
pixel size, but the current implementation should err on the side of
forcing back these frames that are on the fence, which seems more
helpful anyway.

> - Currently, desktop-restore-frames is enabled by customize. In some
> cases, it seems it would be useful to be able to easily enable/disable
> it, either as an argument to desktop-save-mode or as a new
> pseudo-minor-mode.

I'd still like to do that, if we can decide on the UI.

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

> - Other than desktop-filter-parameters-alist, I have not added any
> low-level hook to allow tinkerers to piggyback into the save&restore
> mechanics. I suppose the existing hooks and advice-add should suffice,
> but if someone has anything specific in mind that would require other
> entry points, I'm all ears.

I added `desktop-before-saving-frames-functions'. It is not a filter,
it is just called for each frame before saving its state.

I also added a desktop-specific frame parameter `desktop-dont-save',
which if non-nil precludes the frame from being saved (this can of
course be set from a function in
`desktop-before-saving-frames-functions'). I intend to add a few more
to allow elisp programmers to control what is done with frames;
examples of things that could be useful are `desktop-dont-clear',
`desktop-keep-display', etc. Personally, I like doing this with frame
parameters (over filter functions) for a few reasons:

- This mechanism is easier to extend that adding more and more hooks
or variables.
- (Except in the obvious case of desktop-dont-save) they are
automatically saved & restored along with the rest of frame
parameters.
- Are easy to set when creating the frame, via
(initial|default|pop-up|minibuffer|special-display|window-system-default)-frame-alist
or other methods.

Is anyone opposed to doing things that way?


NEW ITEMS:

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

- Drew asked me to modularize the desktop-restore-frames code so you
can call it to save one frame or a set of frames, and also to modify
`desktop-save-frames' to return the state (instead of modifying a
global variable) and `desktop-restore-frames' to get the state from an
arg (or better yet, I think, to extract from it a function that
encapsulates the restoration of one frame), among other things. On one
hand, I think that's a sensible request (certainly making the code
depend a bit less on global variables is always good). On the other
hand, saving & restoring frames is not the kind of operation that
makes much sense in isolation. Being able to restore a frame/window
config depends not only on the existing buffers, but also on
minibuffer frames, etc, if it is minibufferless. Currently, saving
frames changes (slightly) the state of all frames, because it
necessarily detects minibufferless/minibuffer frame relationships and
adds desktop--mini to all frames. I'm not really sure where to go from
here.

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

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


> * THINGS KNOWN NOT TO WORK:
>
> - Minibuffer(less|-only) frames do not survive the roundtrip to tty
> and back. It could be made to work, but it is a bit complex and I'm
> not sure how useful / necessary it really is.

Not fixed. Very low priority.

> - On Windows, invisible frames turn visible the second time they are
> restored, as an interesting consequence of bug#14841.

This was fixed by Eli.


> * BADLY NEEDED TESTING:
>
> - Non-Windows environments.
> - Anything "multi": multiple displays, multiple monitors, complex
> multi-frame setups, multiple terminals, etc.
> - daemon mode.
> - GUI and tty frames in the same session.

Still needing testing. I refuse to believe that lack of bug reports
means everything's working flawlessly.

   Juanma