alphapapa
Feature request: associate an activity a collection of frames?
I use a tiling window manager and run Emacs as a daemon, opening frames with a simple keyboard shortcut.
In my workflow, I tend to have five or six frames dedicated to a single project, each frame usually containing a single window (and at most three windows), which mostly display Org and PDF buffers.
I often switch projects during the day, which usually means switching to a different desktop "workspace" while leaving the previous project's frames open, and then opening a new set of frames, windows and buffers. Rinse and repeat.
I don't usually kill Emacs or restart my system more often than every three weeks or so, and in that time I can accumulate a lot of frames and buffers. I was hoping that activities.el would allow me to save or bookmark a collection of frames associated to one project, and then kill those frames when switching to another project, while being able to restore the first set of frames when I want to return to them.
Is this possible to implement in the future? I have seen a couple of similar requests on Reddit, and someone with a similar work flow opened a related issue here.
Is this the same as having multiple tabs per activity? If that is the case, I'll second this request :smile:
Hi,
This seems like a reasonable idea. It would require some significant changes and some careful design. I probably won't have time to work on it soon. In the meantime, feel free to brainstorm some ideas about what the UI/workflow would be like, and about how the internal representation of the data might work.
Thanks.
Is this the same as having multiple tabs per activity? If that is the case, I'll second this request 😄
It seems similar, but I'm not sure as I don't use tab-bar-mode. Storing tabs and storing frames might be difficult though.
In the meantime, feel free to brainstorm some ideas about what the UI/workflow would be like, and about how the internal representation of the data might work.
I haven't looked at the internals of activities.el, but I use the Bookmarks+ package to save my entire Emacs desktop -- which includes the frames and buffers of all the projects I was working on -- into a single desktop file that I've bookmarked as desktop-latest, and load the desktop file after restarting Emacs. My understanding is that the whole frameset can be saved to the Emacs registers as well. I wonder if it's possible to use the desktop/register functionality to save subsets of the entire frameset.
@deen1 See also my earlier package, burly, which allows multiple frames to be bookmarked (all of them, not a subset). Saving a subset should certainly be possible; it's a matter of designing the UI and writing the code, which will require some changes. desktop and register functionality isn't relevant or needed.
I'd be happy naming my frames with some agreed-upon scheme to collect them in an activity frame group, and the tabs under them in the frame, of course. It would be ideal to pick and choose not just an activity group but any sub activities by frame or by tab to restore. As long as one can "reparent" a tab between frames, it seems workable to provide personal automation for one's own preferences after activities supports the basic group ability discussed here and also #3 and #78.
I'm definitely in favor of implementing some kind of multi-activity functionality.
There are two basic choices as I see it: 1) implement something like "activity groups" on top of existing functionality, or 2) extend and refactor existing functionality so that each activity could have one or more sub-activities, and then the existing commands could be used to activate either one activity or an activity and its sub-activities.
I think I favor the latter approach, because I feel like having sub-activities is a smaller conceptual change than adding "activity groups" would be.
The biggest challenge will be to make the UI and workflows simple and easy to use, e.g. making an activity a sub-activity, making it a top-level activity, etc. We'd likely also need some enhanced UI to view activity hierarchies (maybe we could use the hierarchy library for that.
Happy to hear further exploration and refinement of these ideas. Thanks.
This could easily be a separate affiliated package (activities-groups?). It would be trivial to mock-up right now, with a hand edited set of groups:
(require 'activities)
(defvar activities-groups
'(("cool group" "one-activity" "another" "the last")
("better group" "two-activity" "yet-another" "best-activity"))
"Groups of activites to resume together.
An alist with group name as key and associated activity names as
the value.")
(defun my/activities-group (group)
"Resume all the activities in GROUP."
(interactive
(list (completing-read "Select an activity group: " activities-groups)))
(when group
(dolist (name (cdr (assoc group activities-groups)))
(when-let ((act (activities-named name)))
(activities-resume act)))))
Then it's just a matter of providing an interface for creating/editing/removing groups, and maybe giving it annotation support.
How about a naive implementation of groups using activity-name prefixes?
e.g., one could use "webproject-" as a common prefix as in "webproject-code" "webproject-deploy" "webproject-debug".
A configuration option activities-group-name-separator, in this case, would be set to "-". activities would have to enforce that only one separator be allowed in activity names. When nil, no enforcement is performed. People who don't want groups can simply set the separator to nil. If the separator is set and an activity is defined with a name that excludes the separator, then people get normal behavior. Easy to have either or both.
Seems more dynamic and natural than to predefine a group and one can add tabs/frames as needed on the fly.
One could use activities-resume as is, using a "fully-qualified" activity name such as "webproject-code" to load that activity.
A new function activities-resume-group would take a group prefix; e.g., "webproject". When the separator is nil, activities-resume-group could complain.
I suppose a -group version of each top-level function would be needed to switch, suspend, kill, discard, etc. No real UI needed other than scanning known activity names for common group prefixes to present a group list. Perhaps activities-list could have some kind of group ability. Or maybe it ignores groups and create activities-list-groups.
Not precisely sure if the -tab versions of the functions need modification.
See also: https://github.com/alphapapa/activities.el/discussions/106
In fact, let's consolidate discussion there, please.