FYI, I’ve recently released a new package called activities. It’s available on GNU ELPA, so it can be installed with M-x package-install RET activities RET.
Please see the documentation (readme file/Info manual (i.e. C-h R activities RET)) for explanations about how it’s designed and how to use it. I’d be grateful for any feedback, including about how the documentation needs to be improved to help new users understand it.
my computer eats lots of your code on daily basis sir alphapapa
Interesting. I think I tried to tackle sort of the same problem, so here are my two cents…
I’m a fan of perspective.el, which has a command to save perspectives. Which saves the window configuration and the associated buffer list. Which, as far as I’m aware, is not an option with your package because tab-bar doesn’t support tab-local buffer lists out-of-the-box 
Although I’ve seen a package for the latter.
However, for my config I ended up doing the inverse of that: automatically assigning perspectives to buffers based on their major mode (with after-change-major-mode-hook). For instance, if I open notmuch it automatically moves to a perspective called mail, and any buffers that are spawned within this perspective do not pollute buffer lists of other perspectives.
I found this workflow works for me better than doing, e.g. persp-state-save when I’m done with mail and persp-state-restore when I want to return to it.
There must be a misunderstanding, because that is the whole point of activities: to restore a window configuration and its buffers, as the documentation, summary, and commentary all explain. 
By
window configuration and its buffers
do you mean just the window configuration and which buffers are shown in which window? E.g. if I open a buffer in an activity and bury it, will it be saved by M-x activity-suspend?
perspective.el would save the buffer if it were opened in a perspective
No, windows’ previous-buffer lists are not saved. I am considering whether to add that feature. It would likely need to be optional.
perspective.elwould save the buffer if it were opened in a perspective
No it wouldn’t, because perspective can’t restore buffers that aren’t file-backed or still open. This is the key advantage that burly has provided (since 2020) and one that activities now provides as well. (I do explain all this in the documentation, but who reads that.)
Hey, this seems really cool.
When I tried it yesterday, I think it didn’t work because “resume” didn’t do anything.
I tried again today and saw that there is a “revert”. Works wonderfully after that.
So I think what happens is that if you work in an activity frame (I’m not using tab-bar-mode), then rearrange windows and call “resume”, activities thinks the activity is still active and does nothing? Then a revert fixes it?
In case I understood this correctly, is it possible to either give hint or use “revert” as a fallback when “resume” is called with the same activity that is currently open?
Please see the documentation. The commands and workflow are explained in detail.
I kind of understand what it does but a screencast would help clarify a lot his it behaves.
From reading the doc, it looks like burly Bufler workspaces with auto save. But cant tell the behavior is that
I think it’s ultimately hopeless. I’ve been trying to explain how these packages work for nearly 4 years now. Everyone has their own idea of what “workspace” means and what “perspective” is and what “saving” and “switching” and “resuming” means. And essentially no one reads the documentation, no matter how carefully it’s written.
Some people will try it and get it; other people won’t try something until they think they understand it, so they never will. Seems like it’s largely a matter of human personality types. That’s life, I guess.
You’re right. The workflow section explains it and this is actually desired. So you can temporarily modify an activity. This is even better. I also love the integration with bookmarks.
Sorry that you think it’s hopeless. I may have asked my previous question too early and your hint with the workflow lead to me reading the workflow section again, which answered my question.
When something is new, it’s hard to keep everything in ones head (in this case I was reading the descriptions of the functions and missed 4-6 in the workflow).
Overall I think your documentation is excellent. But I also agree with benoitj in that a screencast helps to get an overview. Not something necessarily for the package author to do. That’s what we have david and the community for
I didn’t mean that you are hopeless, and I didn’t say that because of your message specifically. Sorry if I’m a bit grumpy about it. I do feel a bit frustrated, because I’ve been trying to explain these tools for years now, and it seems like no matter how carefully I try to explain, it’s never enough. Some of it is due to users’ generally not reading the docs, or not reading them carefully; some of it is due to the concepts being vague; some of it is due to Emacs’s being so flexible.
It’s frustrating to me because I think this tool solves a real problem, not just in Emacs, but in personal computing (and Emacs is one of the few platforms in computing where this problem even can be solved)–so when people don’t understand, and won’t give it a try, they miss out on something that could be very helpful to them.
So then, when then I see them talking here or there about problems that are solved by these tools (like today on a Reddit thread), and they reject them because they don’t or won’t understand… It’s like the old adage, “You can lead a horse to water…”
I guess it’s like anyone who makes anything: without the right marketing, it won’t be likely to reach its intended audience, or at least, not for a long time.
A screencast is a good idea, of course. I’ve made some for other projects of mine, but they haven’t seemed to help much (even though I carefully scripted and automated every action in the screencast, with enough time between each action to make it watchable).
Well, maybe I’m just grumpy today.
which is why I pointed out a screencast could help
Hey, you literally say that
Comparisons to other packages are left to the reader
But I think the problem is not with your documentation but with me being bad at conveying my understanding.
Also, may I add, from reading your code (org-ql most recently), sometimes I feel like you think at the speed of light compared to me It took special effort on my behalf to unravel just one chain of your abstractions… that also depends on these dash, f, s, etc. Maybe it’s a general problem of figuring out other programmers’ code, but generally I don’t feel like that. But I think I understand how you’re so efficient at writing these packages.
When I’m dealing with anything approaching this level of complexity, I try to document all input/output structures, split up the functions and document what each of them is doing, because otherwise even the tomorrow version of me tends to have a hard time.
Well, anyway, for now I’m definitely too invested in my current workflow to try anything new for workspace/perspective management over a weekend.
Also, I use your burly.el to copy perspectives between EXWM-managed frames. My lowly perspective-exwm is the only MELPA package that depends on burly and not written by you <3 Maybe I’m not entirely hopeless
No, it’s not your fault.
Also, may I add, from reading your code (
org-qlmost recently), sometimes I feel like you think at the speed of light compared to medash,f,s, etc. Maybe it’s a general problem of figuring out other programmers’ code, but generally I don’t feel like that. But I think I understand how you’re so efficient at writing these packages.
Efficiency and speed come from repetition. If you had spent as much time as me writing Elisp libraries, it would seem easier to understand them. You’re probably better at writing in some other languages or types of programs than I am.
But be careful not to assume how long it took to write code. It may be published in a moment, but it may have taken many hours of making mistakes to get to where it is now.
When I’m dealing with anything approaching this level of complexity, I try to document all input/output structures, split up the functions and document what each of them is doing, because otherwise even the tomorrow version of me tends to have a hard time.
I mostly do that too. Emacs even complains if symbols don’t have docstrings. To me one of the most important things to document is functions’ return values and side effects, because that can save someone (including “future me”) from having to read the code.
Well, anyway, for now I’m definitely too invested in my current workflow to try anything new for workspace/perspective management over a weekend.
You don’t owe me anything. Try it if you feel like it, but it’s fine if you don’t.
Also, I use your burly.el to copy perspectives between EXWM-managed frames. My lowly
perspective-exwmis the only MELPA package that depends onburlyand not written by you
Cool. I didn’t know it had any other dependents.
<3 Maybe I’m not entirely hopeless
No one is hopeless.
Hey @alphapapa this looks like a cool package, is very similar to how I’m currently using perspective + perspective-tabs. Changing tabs changes the perspective, the problem is that perspective does not integrate very well with tabs (by default) and with some operations that change buffers. This looks like a nice replacement.
Some feedback.
Minor issues.
I’m considering this feature, but it has the potential to cause problems, because it could end up restoring a bunch of buffers that aren’t relevant or wanted.
Also if I’m already in an activity, how do I start a new one quickly (activities-new uses the current window config which seems confusing, maybe clear to a temporary read-only buffer).
Everyone seems to have their own idea of what the commands should do. I don’t know if it will be possible to please everyone.
As the docs explain, activities is designed to coexist with other features. A frame/tab is merely associated with an activity. You can make a new frame/tab at any time using Emacs’s commands. You can then associate it with an activity if you want to.
Would it be possible to define how the tab-bar names look?. I’m displaying the name in the mode-line and it looks like this: a emacs, a code. A bit too long, I usually care about descriptive name for saving restoring perspectives but I use short names (1,2,3,4) for tabs.
That function could be customized. Please feel free to file a request on the tracker.
I find useful when packages have the line “This file is NOT part of GNU Emacs”. This way I can tell if the package is built in (like transient). I usually go to the top of an emacs lisp file to check.
activities is considered “part of GNU Emacs” because it is in GNU ELPA.
If you want to know whether a package is built-in, you can use C-h P (and marginalia even shows that status in the minibuffer, so you need not finish the command).
Thanks for your feedback.
I’ve been using this package for a couple of weeks now and it fits my particular workflow incredibly well.
I have several projects running concurrently, that I have notes/documentation, time cards and reference material open for in several tabs.
activities.el enables me to save the state of all open activities when i close emacs (yes, I clode emacs) and then revert to the same state when re-opening emacs.
I think I have a total of seven (7) activities saved at the moment.
Great package. Than you @alphapapa
Thanks, Glenneth, I’m happy to hear that it’s fulfilling its intended purpose for you!
By the way, let me make a small suggestion: Since you have several activities defined and are using them regularly, you might want to make a regular backup of your ~/.emacs.d/persist/activities-activities file; a few days ago I found that mine had gone missing, which means I lost all the defined activities. I’ve no idea what happened; it might have something to do with my having to kill the Emacs process at some point, but I didn’t think it would have that effect, and other such variables didn’t disappear. Anyway, I wouldn’t want you to have to recreate all those activities from scratch, so making a backup of that file now and then might be a good idea, at least until I find out if it’s really a bug.