Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
che2 opened this issue Dec 21, 2014 · 11 comments
Open

Comments

@che2
Copy link
Contributor

che2 commented Dec 21, 2014

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.

@nex3
Copy link
Owner

nex3 commented Jan 5, 2015

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.

@colonelpanic8
Copy link

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

@che2
Copy link
Contributor Author

che2 commented Jan 28, 2015

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

@tmccombs
Copy link

tmccombs commented Mar 3, 2015

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

@localredhead
Copy link

👍

@nex3
Copy link
Owner

nex3 commented May 8, 2015

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

@Bad-ptr
Copy link

Bad-ptr commented Aug 14, 2015

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.

@Pitta
Copy link

Pitta commented Aug 12, 2021

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.

@gcv
Copy link
Collaborator

gcv commented Aug 12, 2021

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.

@Pitta
Copy link

Pitta commented Aug 17, 2021

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

@gcv
Copy link
Collaborator

gcv commented Aug 17, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants