perspective-el icon indicating copy to clipboard operation
perspective-el copied to clipboard

Perspectives lost after last frame is closed when running in daemon mode

Open che2 opened this issue 10 years ago • 11 comments

By default, perspectives are not shared between frames. To import a perspective to another frame, the 'persp-import' command can be used. This works as expected as long as the frame from which perspectives are improted is still open, but once that frame is closed, the perspectives belonging to the frame are lost forever, and the only way to recover the buffers from those lost frames are to either: o use 'persp-add-buffer' to add each buffer manually o shut down persp-mode

This is not ideal, especially in daemon mode, where the last frame would frequently be closed logging out of an ssh session, but perspectives are gone when a new frame is created in the same emacs daemon after logging back in.

I suggest that either:

  • Add an option to share perspectives between all frames (which is done by https://github.com/Bad-ptr/persp-mode.el).
  • Automatically transfer any perspectives to a closed frame to one of the remaining frames, and if the last frame is closed in daemon mode, the perspectives are automatically transfer to the first new frame is that is created from the same daemon.

Option 1 is probably the simplist to implement (it's already done by persp-mode), and also a good work around to the problem. Option 2 is arguably more sane, as it fixes the (broken) behavior.

che2 avatar Dec 21 '14 04:12 che2

I like option one. In general, I think it's confusing if perspective data persists invisibly beyond the frame that owns them, but users who use daemonized instances a lot should have a way to persist perspectives.

I'd be open to merging in @Bad-ptr's implementation.

nex3 avatar Jan 05 '15 23:01 nex3

status? @che2 Would you be willing to incorperate the solution from @Bad-ptr ?

colonelpanic8 avatar Jan 15 '15 18:01 colonelpanic8

@IvanMalison, I am currently using #42 which implements solution 2 - transfering the workspaces of a frame when it is closed. I am personally happy with this solution.

@nex3, would you be open to merge the open pull request? I think it doesn't have drawbacks compared to the existing behavior:

  • if you are using one frame for all your workspaces, then nothings changes
  • if you are using multiple frames, the current behavior is that closing one of the frames results in the loss of all workspaces belonging to that frame, which is very likely undesirable. The new behavior is that the workspaces of that frame gets transferred to another live frame, which IMO is more desirable. If a user doesn't like this behavior, he can set up a hook to kill all of the workspaces of a frame on close.

che2 avatar Jan 28 '15 20:01 che2

I would like to have an option to share perspectives among all frames, as described in option one.

tmccombs avatar Mar 03 '15 05:03 tmccombs

:+1:

localredhead avatar May 06 '15 06:05 localredhead

@che2 I've done a review of your PR.

nex3 avatar May 08 '15 22:05 nex3

For those who interested: https://gist.github.com/Bad-ptr/aa6be231fdc22705ca19

This is my attempt to solve these issues, as I see it. My idea is to introduce perspectives-sets (actually it could be called "virtual-frame" or "persp-frame-config", cause it just mirrors all frame-local variables in a structure). This code allows to save/load from file, and keep perspectives from killed frames.

How to use: load the perspective.el (require 'perspective), then load the perspectives-set.el (save it somewhere, then (load-file "/path/to/perspectives-set.el")), then enable the persp-mode. Try out persps-set-kill, persps-set-rename, persps-set-switch and of course persp-save-state-to-file and persp-load-state-from-file functions.

Anyone want to test it?

// Hm.. found a bug -- "Marker does not point anywhere" error, after loading from file. Strange. // Fixed.

Bad-ptr avatar Aug 14 '15 19:08 Bad-ptr

As someone who uses the daemon almost exclusively, having perspectives tied to the daemon as an option vs the frame that spawned them would be immensely helpful.

I could be working from my desktop, then grab my laptop to change the scenery and then pick up and run with the same workflow/perspectives.

I was doing this already before perspective, but we all know that's less desirable after rocking perspective.

Pitta avatar Aug 12 '21 20:08 Pitta

I bet this will be way easier to get working if I ever get around to merging in #91.

As a workaround, you can save the perspectives to a file using persp-state-save, and then restore them in a different "frame" using persp-state-load. I get that it's more manual than letting the daemon have its own perspective state, though.

gcv avatar Aug 12 '21 21:08 gcv

@gcv - I have tried getting persp-state-save and persp-state-load to work, but doesn't seem to. File gets written, but loading it doesn't seem to do anything after I close the current frame and try to load from a new one.

Pitta avatar Aug 17 '21 20:08 Pitta

The problem might be that it's designed to save and restore full Emacs state, meaning multiple frames. Whereas your use case is (IIUC) mainly about one frame. It would take some refactoring to extract a single-frame use case. I don't have time to work on it right now. If you know Elisp, I'd be glad to look at a PR.

gcv avatar Aug 17 '21 22:08 gcv