desktop-restore-frames

desktop-restore-frames

[Juanma Barranquero]

OK, I've just committed a change to desktop.el which enables
desktop-restore-frames by default.

At this point, the code is working well enough in my setup, which alas
is wholly Windows-specific. So it's time to let the little bird fly
and start receiving suggestions, feedback, bug reports and possibly
blunt force trauma.

* ADDED:

- Option restore-in-current-display now offers three possibilities: t,
which forces frames to the current display; nil, which allows each
frame to go to their display, and delete, which restores frames in the
current display and deletes others.

- New option desktop-restoring-reuses frames, with three possible
values: reuse existing frames (if possible, else delete them), delete
existing frames (and create new ones for saved frames), and keep the
existing ones (and restore saved frames in new ones).  A problem with
`keep' is that is more useful for M-x desktop-read than for the
initial read, because it does keep the initial frame, which is likely
not what the user wants. Workarounds include adding code in your
.emacs to delete that frame:

(setq *initial* (selected-frame))
(add-hook 'desktop-after-read-hook
          (lambda ()
            (when *initial*
              (ignore-errors (delete-frame *initial*))
              (setq *initial* nil))))

or adding a new option, if necessary.

- Support for minibuffer-only and minibufferless frames. In many
normal setups, saving & restoring these kind of frames should work as
expected.  I haven't added an option to skip restoring minibuffer-only
frames, as Drew suggested. Let's try this first and I can add it
afterwards if required.

- Workaround for bug/feature/infelicity#14795. Now frames should be
restored with the right height, regardless of their tool-bar-mode
setting.

- Vastly improved parameter filtering. It now allows setting filtering
functions to precisely determine when and how parameters are passed
untouched, removed or modified. As a corollary, fullscreen,
size/position and font parameters survive the tty roundtrip intact.


* 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.
- 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.
- 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.
- All names are up for discussion, of course. I'm really bad at naming
functions and options. Also, suggestions to make docstrings clearer
are very welcome.
- 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.
- Some of this stuff, once polished, should be documented in the elisp
or emacs manual. Not by me, though, sorry.


* 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.
- On Windows, invisible frames turn visible the second time they are
restored, as an interesting consequence of bug#14841.


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

I think that's all.

Enjoy,

    Juanma

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

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

Re: desktop-restore-frames

[Juanma Barranquero]

On Mon, Jul 29, 2013 at 9:54 AM, martin rudalics <rudalics@gmx.at> wrote:

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

Well, yes, sure (one, or two if using a minibufferless /
minibuffer-only setup). But my point is that desktop-clear allows the
user to set up buffers s/he doesn't want to "clear", so perhaps it
makes sense todo the same with frames. OTOH, perhaps not, and just
going for the easy kill-them-all, Simon de Monfort's style.

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

Yes.

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

OK.

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

That, and also that it restores "dead" frames.

    J

Re: desktop-restore-frames

[martin rudalics]

 > Well, yes, sure (one, or two if using a minibufferless /
 > minibuffer-only setup). But my point is that desktop-clear allows the
 > user to set up buffers s/he doesn't want to "clear", so perhaps it
 > makes sense todo the same with frames. OTOH, perhaps not, and just
 > going for the easy kill-them-all, Simon de Monfort's style.

Every buffer must have a name.  Naming frames is less convenient so I'd
use the kill-them-all approach.

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

So the selected frame is that window's frame.

 >> It has the advantage that we can save "something like" registered frame
 >> configurations to disk and read them back.
 >
 > That, and also that it restores "dead" frames.

Which is a considerably advantage.

martin

Re: desktop-restore-frames

[chad]

On 28 Jul 2013, at 06:34, Juanma Barranquero <lekktu@gmail.com> wrote:
> 
> - 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.

This sounds like the Eclipse `Perspective' feature that was discussed
and wanted ~last year. I've done something similar in the past with
X resources, named frames, and hardcoded elisp, so I'd guess that
people will find it useful. (Apologies if this seems obvious; I'm
catching up while on the road).

Thanks again for making this happen!
~Chad

Re: desktop-restore-frames

[Juanma Barranquero]

On Mon, Jul 29, 2013 at 1:47 PM, chad <yandros@mit.edu> wrote:

> so I'd guess that people will find it useful.

Yes, I think so. People uses frame-configuration-to-register and
window-configuration-to-register nowadays, and that's the same
feature, on steroids.

>  (Apologies if this seems obvious; I'm
> catching up while on the road).

Nothing to apologize for. Thanks for your comments.

   J

Re: desktop-restore-frames

[joakim]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Mon, Jul 29, 2013 at 1:47 PM, chad <yandros@mit.edu> wrote:
>
>> so I'd guess that people will find it useful.
>
> Yes, I think so. People uses frame-configuration-to-register and
> window-configuration-to-register nowadays, and that's the same
> feature, on steroids.
>
>>  (Apologies if this seems obvious; I'm
>> catching up while on the road).
>
> Nothing to apologize for. Thanks for your comments.

I havent followed the thread, so just ignore this if I'm off-base. I suppose
you already looked at Winner mode, and the other various Emacs window
state remembrancers? I dont think they persist state normally though,
and I normally just use window-configuration-to-register in my own code.
(mod-depop, part of zen.el)
>
>    J
>

-- 
Joakim Verona

Re: desktop-restore-frames

[Juanma Barranquero]

On Mon, Jul 29, 2013 at 1:58 PM,  <joakim@verona.se> wrote:

> I suppose
> you already looked at Winner mode, and the other various Emacs window
> state remembrancers?

Not really, though I was aware that such packages exist. My focus is
heavily on persistence. For on-session uses, a single display, etc,
I'm sure existing solutions are enough.

OTOH, once I modularize frame-states, winner etc. could use them to
enhance their experience, I suppose.

   J

Re: desktop-restore-frames

[Angelo Graziosi]

Juanma Barranquero wrote:
> Still needing testing. I refuse to believe that lack of bug reports
> means everything's working flawlessly.

I am still here... :-)

For desktop, I use only "(desktop-save-mode t)"  in the init file, and 
the restoration seems good. Usually I use one frame with 3 windows (and 
many buffers) and don't notice big issues if not those regarding the 
maximize/fullscreen problems described here:

   http://lists.gnu.org/archive/html/emacs-devel/2013-07/msg00142.html

This seems to affect only the GTK build on Cygwin...

I can add only this: once the maximizing button has been selected, in 
the subsequent sessions, the frame is restored almost maximized but with 
the maximizing button unselected so that one can no longer reset the 
frame dimensions to the default values (a frame that looks like a square).

Other than that, it looks like you did a good work. Thanks!


Ciao,
  Angelo.

Re: desktop-restore-frames

[Juanma Barranquero]

On Mon, Jul 29, 2013 at 12:21 AM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> I am still here... :-)

Well, *thanks*. I had a distinct impression of talking to myself... ;-)

> I can add only this: once the maximizing button has been selected, in the
> subsequent sessions, the frame is restored almost maximized but with the
> maximizing button unselected so that one can no longer reset the frame
> dimensions to the default values (a frame that looks like a square).

Yes, there's the problem already stated that I cannot detect that the
frame is really maximized (for the window manager). I think I cannot
do anything at all about this issue.

Couldn't you just run emacs with '(fullscreen . fullscreen) in
`initial-frame-alist'.

> Other than that, it looks like you did a good work. Thanks!

Thanks, though I'm fixing a bug right now... :-)

   J

Re: desktop-restore-frames

[Angelo Graziosi]

Il 29/07/2013 0.37, Juanma Barranquero ha scritto:
> On Mon, Jul 29, 2013 at 12:21 AM, Angelo Graziosi
> <angelo.graziosi@alice.it> wrote:
>
>> I am still here... :-)
>
> Well, *thanks*. I had a distinct impression of talking to myself... ;-)
>
>> I can add only this: once the maximizing button has been selected, in the
>> subsequent sessions, the frame is restored almost maximized but with the
>> maximizing button unselected so that one can no longer reset the frame
>> dimensions to the default values (a frame that looks like a square).
>
> Yes, there's the problem already stated that I cannot detect that the
> frame is really maximized (for the window manager). I think I cannot
> do anything at all about this issue.


Just for completeness, I want to flag a different behavior I noticed 
after Cygwin GTK libraries upgrade to 3.8 [*].

With GTK 3.6 restarting Emacs produced a frame almost maximized but with 
the maximizing button not selected; now, with GTK 3.8, the frame just 
for an instant looks as before (almost maximized) but suddenly is 
restored to its default dimensions (almost a squared box about 40 rows x 
80 columns), so that I need to re-maximize it each time. All the windows 
of previous sessions and buffers are restored correctly.

 >
 > Couldn't you just run emacs with '(fullscreen . fullscreen) in
 > `initial-frame-alist'.

May you tell me what I need to add to the init.el file?

Thanks,
Angelo.

---
[*] http://cygwin.com/ml/cygwin-xfree/2013-08/msg00017.html

Re: desktop-restore-frames

[Angelo Graziosi]

Il 14/08/2013 10.45, Angelo Graziosi ha scritto:
> Il 29/07/2013 0.37, Juanma Barranquero ha scritto:
>
>  >
>  > Couldn't you just run emacs with '(fullscreen . fullscreen) in
>  > `initial-frame-alist'.
>
> May you tell me what I need to add to the init.el file?

OK, I have tried this

(setq initial-frame-alist (quote ((fullscreen . maximized))))

and then this

(setq initial-frame-alist (quote ((fullscreen . fullscreen))))


but both have the minibuffer covered by the status bar... :-(

> Thanks,
> Angelo.
>

Re: desktop-restore-frames

[Juanma Barranquero]

On Wed, Aug 14, 2013 at 12:19 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> but both have the minibuffer covered by the status bar... :-(

This happens even if you don't use desktop.el, doesn't it?

So it's an Emacs bug / window manager bug / weird interaction between
them. Something to file a bug report about, in any case.

   J