Some thoughts on Activities

[gcv]

Overall, I think Activities is really promising. I have a few questions/suggestions:

• What’s the difference between activities-resume and activities-switch. They seem to do the same thing, so maybe they can just be one command? Maybe activities-new can also be consolidated into the same command.
• I’m not sure how to remove a buffer from an activity.
• I’d like a way to make a blank activity, rather than one that inherits the buffer list.

[alphapapa]

Overall, I think Activities is really promising. I have a few questions/suggestions:

* What’s the difference between `activities-resume` and `activities-switch`. They seem to do the same thing, so maybe they can just be one command? 

The documentation should explain the difference. Please let me know if it's not clear.

Maybe activities-new can also be consolidated into the same command.

I don't think it would make the UI clearer to combine the command that defines a new thing with the command that activates an already-defined thing.

* I’m not sure how to remove a buffer from an activity.

I guess there's a misunderstanding, because buffers are neither added to nor removed from activities. An activity has an associated window configuration, within which each window has a buffer displayed in it. If you want to change the buffer shown in a window, or change the window configuration, then arrange the windows and buffers to your liking, and then (re)define the activity.

* I’d like a way to make a blank activity, rather than one that inherits the buffer list.

Along the same lines, this seems to be a misunderstanding. An activity cannot be "blank"; one devoid of saved states would be useless.

Note that the list of buffers shown in an activity's tab is not saved and restored across sessions.

[lrustand]

Note that the list of buffers shown in an activity's tab is not saved and restored across sessions.

Then what is the point? Why keep track of a separate list of buffers that is supposedly part of the activity, if it in fact is not part of it? This would make sense if the list was real, and that it was saved as part of the activity. Or it could also make sense that the activity is just the currently visible buffers, but then the separate buffer list feels weird and doesn't seem to represent anything real.

Either way, if there is a separate list of buffers, then we need a way of removing buffers from it otherwise it will become very cluttered very fast.

[alphapapa]

Buffers serve a variety of purposes within the context of an activity (in the general sense of the word activity). Some of them are ephemeral (like help or info buffers, various Dired buffers showing subdirectories of a project, etc). It's useful to offer them when switching buffers during a session, but they are not necessary to preserve across sessions, because they are not fundamental to the activity.

I've been using Activities as a fundamental part of my Emacs usage patterns for about 8 months, and in practice, there is no problem. When switching to a buffer with activities-switch-buffer, I see recently used ones, type a few characters to narrow the list with completion using Vertico, and choose the buffer I need. When I suspend or kill an activity, the list of associated buffers is cleared. When I resume it, the list only has buffers that are visible in the activity. There is no very cluttered list of buffers to deal with. There's simply no problem here that I can see.

Have you used Activities yet? Have you experienced such a problem?

[lrustand]

Have you used Activities yet? Have you experienced such a problem?

Yes, of course I have used it otherwise I wouldn't have noticed the problem. After just a few hours of use the list is already over 75% unwanted buffers, which makes the list not very pleasant to work with. I would like to be able to say "I'm now finished with this buffer and do not need it anymore inside of this activity", just like I can in normal emacs by simply deleting the buffer.

[gcv]

Then I don't understand the purpose of an activity-specific buffer list. If an activity has an associated buffer list, then it should be possible to remove a buffer from it. I guess I also don't understand the creation of new activities. An activity in my mind should start as a blank slate, not a fork of an existing activity.

Laying my cards out on the table: I fell into maintaining Perspective because I was willing to fix a bunch of long-standing bugs and add a few needed features. Perspective has an old codebase and a few bugs and corner cases that are difficult to fix or improve upon. I'm wondering if Activities can make Perspective obsolete the same way Vertico makes other completion frameworks obsolete (except maybe Helm). This wouldn't be a bad thing at all (I don't mind maintaining fewer things!). So I'm looking to see if Activities can do what Perspective does, at least for my needs.

Perspective goes to great lengths to keep a perspective-specific buffer list (along with a window configuration). Although the user may decide to have multiple perspectives share a buffer, any behavior that results in a buffer "leaking" into another perspective is a bug. Adding and removing buffers from perspectives are important operations.

Reading the project description, it seemed to me that Activities manage buffer lists along with window configurations. If this isn't where you're going with Activities, that's cool.

[alphapapa]

Please note that kill-buffer actually kills a buffer. The hypothetical function you describe would not kill a buffer but merely remove it from a list of recently used buffers. The two actions are fundamentally different.

Yes, I'm aware of that, and I left out a few details of my described usecase. In this hypothetical situation that command would ideally also check if the buffer is visible in any other activities apart of any currently active activity, and if not then actually kill it.

That does sound it like could be useful. It could be a candidate for an activities-kill-buffer command. Feel free to send a patch or file a feature request about it.

But given that it generally goes against a principle upon which this package is designed (i.e. taking care of such minor details automatically rather than expecting the user to "clean up after himself,"), I don't intend to work on such a feature myself.

But the problem is that it DOES NOT take care of it AT ALL, neither automatically nor manually. It NEVER deletes anything from this list unless I restart emacs, which if I prefer to do as seldom as possible.

Specifically, in the current implementation, the activities-buffer-list is stored as a tab parameter, so the list should be cleared when an activity's tab is closed (which should happen when suspending or killing an activity).

But I still don't understand why you would even add this list without persisiting it. The list makes no sense if it is completely unrelated to the activities functionality.

I don't understand why you don't understand. The rationale for that list has been explained two or three times in this discussion.

[lrustand]

Specifically, in the current implementation, the activities-buffer-list is stored as a tab parameter, so the list should be cleared when an activity's tab is closed (which should happen when suspending or killing an activity).

Well, that may be true. But the way I have been using activities is to just leave them open in the tab bar, and not close them at all. (At least this is what I have done until now. I guess if I would use it for an extended period of time I would probably close a tab once in a while probably, but most of them would still be open at all times.)

I don't understand why you don't understand. The rationale for that list has been explained two or three times in this discussion.

I'm not the one that doesn't understand. Oops, I guess I did actually say those words.

[alphapapa]

Specifically, in the current implementation, the activities-buffer-list is stored as a tab parameter, so the list should be cleared when an activity's tab is closed (which should happen when suspending or killing an activity).

Well, that may be true. But the way I have been using activities is to just leave them open in the tab bar, and not close them at all. (At least this is what I have done until now. I guess if I would use it for an extended period of time I would probably close a tab once in a while probably, but most of them would still be open at all times.)

Ok, that's up to you. (One of the fundamental ideas of Activities is that the activities can easily be suspended and resumed with integrity, so leaving them open indefinitely, even when unused, is, to some degree, missing the point. But to each user, his own.) Anyway, with use of various completion facilities, it's hard for me to imagine the size of the activities-buffer-list being a problem. But if it is, I've suggested ways to address it.

I don't understand why you don't understand. The rationale for that list has been explained two or three times in this discussion.

I'm not the one that doesn't understand.

Please don't be rude. There's no need for it, especially here, among what should be considered something akin to colleagues, fellow Emacs users.

I understand that your preference would be to manually remove buffers from the list. I've suggested some ways to provide such functionality. I don't want to spend time on implementing such functionality myself, but I'm willing to offer feedback to someone who does.

[lrustand]

Please don't be rude. There's no need for it, especially here, among what should be considered something akin to colleagues, fellow Emacs users.

You're right, I'm sorry. I read your comment a bit too quickly, so I thought you were being rude first, but it turns out you simply repeated part of what I had said. I edited my previous comment to reflect this.

[alphapapa]

Please don't be rude. There's no need for it, especially here, among what should be considered something akin to colleagues, fellow Emacs users.

You're right, I'm sorry. I read your comment a bit too quickly, so I thought you were being rude first, but it turns out you simply repeated part of what I had said. I edited my previous comment to reflect this.

No problem. Thanks. I appreciate your interest in Activities and would welcome your contributions.

[alphapapa]

I guess I also don't understand the creation of new activities. An activity in my mind should start as a blank slate, not a fork of an existing activity.

Defining a new activity simply assigns the current window configuration to a new activity. It's kind of like write-file: it's generally not that useful to write an empty file. Of course, you can find-file on a nonexistent filename and get an empty buffer. But the equivalent for activities would be, e.g. C-x 5 2 or C-x t 2 to open a new frame or tab, and then C-x C-a C-n to define it as a new activity--if you decide that you want to define one.

In other words, the intended workflow (so far) is more like "Hm, this window configuration looks useful, I'll define it as an activity so I can use it again," more than, "Hm, I want to do something, let me make a new activity in which to begin doing it." But, again, nothing stops you from make-frame + activities-new if that's what you want to do (just remember that the default state would be blank, so you'd better redefine it once you get it to a useful layout).

Regarding buffer lists: Well, first, maintaining a list of buffers associated with an activity is a very recent addition. This package is also very new.

I added the buffer list initially to allow buffers to be killed when an activity is suspended. Then I just (what, yesterday? haha) added the command to switch to a buffer associated with an activity.

One of the principles I'm trying to follow with this package is that it should be a "good citizen," i.e. it should not interfere with other packages, libraries, or features in Emacs. So, for example, activities does not exert any control over frames/tabs that are not associated with an activity. The user is free to make new frames/tabs, close them, etc, without regard for activities. The user can also kill a frame or close a tab that is associated with an activity, even without using an activities command to do so.

To put it another way, activities provides "mechanism, not policy" (in the classic spirit of the X Window System). It doesn't force a workflow or paradigm upon the user. It provides tools to assist the user in whatever workflows he needs.

Another principle is that it should require minimal direction from the user. The idea of having to manually add or remove buffers from a list is anathema to me. More than that, I don't think the user should need to care whether a buffer is associated with one activity or another.

(I wrote bufler to group buffers programatically; whether it will find some form of integration with activities is yet to be seen. Probably activities needs to gain some more hooks so that other packages like bufler can integrate with it.)

So the way it works now is simple (and only for the tabs mode at the moment): when a buffer is shown in an activity, it is added to the activity's buffer list. But nothing prevents a buffer from being on any other activities' lists as well.

When an activity is resumed, its buffer list starts with just the buffers initially displayed in it. As other buffers are shown in it, they are added to its list; but no activity's buffer list is exclusive to it.

And ultimately I think this is more useful for the user as well: if a user shows a buffer in an activity that is technically associated with another project (e.g. I'm working on activities and I want to open a file from ement to see how I did something similar), that buffer then becomes temporarily associated with that activity--and rightly so, because, for that period of time, it was relevant to it. But tomorrow when I resume that activity again, unless I manually switch to that other buffer, it won't be associated with it anymore. It's kind of like automatic garbage collection.

Now, having said all that, again, this is a young package, and I want it to grow to meet users' needs, within its vaguely defined vision. So I'm certainly willing to discuss the design and entertain features and ways to make it more flexible and powerful. But I generally lean away from patterns that expect the user to manually maintain lists of this or that. I want the computer to make my work easier, not to require more work of me.

I want activities to be nearly trivial to use, so that I can make a new activity anytime, for anything, even a project I'm working on for just a few hours, and then discard it when I'm done, without having to invest effort in setting it up, effort which would deter many uses. And at the same time, I want it to be robust and flexible, so that I can define an activity for a long-term project and continue using and refining that configuration for years to come, saving me hours of time cumulatively.

Well, I hope all that makes sense. Happy to hear your feedback, to have your interest and any contributions you might offer. Thanks.

[gcv]

But I generally lean away from patterns that expect the user to manually maintain lists of this or that. I want the computer to make my work easier, not to require more work of me.

I totally hear you! It's a great design philosophy.

For me, the list of buffers associated with an "activity" or "perspective" is a key part of reminding me what I'm actually doing there. If I'm switching perspectives, it usually means I'm switching contexts. I find context-switching difficult, and the more help I have to remind me, the better. If my project has two tasks, one touching files "file11" and "file23", and another touching "file4" and "file18", then it's really helpful for me to look at the buffer list for the perspective I created for the specific task and remind me that those are the relevant files or buffers. Seeing unrelated buffers pulled into a task-dedicated perspective is really jarring, and Perspective goes to considerable lengths to keep that from happening.

In Perspective, there isn't much pain involved in adding buffers. find-file will automatically add a buffer to the current perspective. The various switch-to-buffer wrappers and hooks provided (that work with all common frameworks and all switching commands built into Emacs) use optional prefix arguments to say "let me pick any open buffer, instead of just the ones associated with the given perspective", which makes it easy to pull an already-open buffer into the current perspective. kill-buffer removes the buffer from all perspectives. There's a dedicated command to remove a buffer from a perspective shared with other perspectives, but I personally don't use it very frequently.

[alphapapa]

For me, the list of buffers associated with an "activity" or "perspective" is a key part of reminding me what I'm actually doing there. If I'm switching perspectives, it usually means I'm switching contexts. I find context-switching difficult, and the more help I have to remind me, the better. If my project has two tasks, one touching files "file11" and "file23", and another touching "file4" and "file18", then it's really helpful for me to look at the buffer list for the perspective I created for the specific task and remind me that those are the relevant files or buffers. Seeing unrelated buffers pulled into a task-dedicated perspective is really jarring, and Perspective goes to considerable lengths to keep that from happening.

Well, I may be wrong, but I think the current implementation of activities provides that behavior, if not exactly, then pretty closely: No buffer will be in an activity's buffer list unless the user chooses to show it in that activity's frame/tab.

Now that could include, e.g. help buffers, if the user looks at one while in an activity. But I have no objection to adding a list of predicate functions, similar to the anti-save-predicates, which would preclude a buffer from being added to an activity's buffer list. Then the user could prevent any buffer from being associated with an activity and thereby shown in its switch-buffer command.

Would that help achieve the behavior you need?

The various switch-to-buffer wrappers and hooks provided (that work with all common frameworks and all switching commands built into Emacs) use optional prefix arguments to say "let me pick any open buffer, instead of just the ones associated with the given perspective", which makes it easy to pull an already-open buffer into the current perspective.

Yeah, bufler-switch-buffer works similarly, offering buffers outside the current workspace's group with more universal prefix arguments. We could do something similar for activities-switch-buffer.

[hpfr]

I made a comment related to the discussion in this issue in #43 (comment) and alphapapa replied in the following comment with some good info including a link to this discussion. This issue is much more related to what I raised, so I’ll reply here to keep the linked issue focused specifically on the current buffer switching implementation.

---

One of the principles I'm trying to follow with this package is that it should be a "good citizen," i.e. it should not interfere with other packages, libraries, or features in Emacs.

I fully agree with trying to keep packages orthogonal and “good citizens”; that’s why I didn’t make this request before, as I assumed it would be out of scope. But from my perspective at least, now that activities-buffer-list and activities-switch-buffer exist, the scope of the package has already expanded to (optionally) include managing a list of buffers beyond the window configuration. So now, rather than polluting the package with a separate concern, serializing this list would make it a more complete solution for its implicit scope. I completely understand if you disagree though—I can only hope that this comment and others like it from folks like @gcv will live in the back of your mind as you continue to iterate on the package in its early days :D.

So, for example, activities does not exert any control over frames/tabs that are not associated with an activity. The user is free to make new frames/tabs, close them, etc, without regard for activities. The user can also kill a frame or close a tab that is associated with an activity, even without using an activities command to do so.

So the way it works now is simple (and only for the tabs mode at the moment): when a buffer is shown in an activity, it is added to the activity's buffer list. But nothing prevents a buffer from being on any other activities' lists as well.

I can’t speak for gcv, but I don’t think what I’m proposing would conflict with these properties. Suspending would just serialize more buffers, and resuming would just load them in the background and restore activities-buffer-list. And this behavior would be behind an option.

The idea of having to manually add or remove buffers from a list is anathema to me. More than that, I don't think the user should need to care whether a buffer is associated with one activity or another.

(I wrote bufler to group buffers programatically; whether it will find some form of integration with activities is yet to be seen. Probably activities needs to gain some more hooks so that other packages like bufler can integrate with it.)

Regarding bufler, I think my first read of the README gave me the impression that this package was meant as a successor to both burly and bufler, but on second look I see that that only applied to burly and the bufler-workspace extension specifically. So I took another look at bufler. At least for me, I am not interested in setting up predefined rules for grouping buffers. project.el is sufficient for 80% of that, and the additional complexity of setting up custom grouping functions could only take me another 10% further or so anyway. I find that the best complement to to the highly structured project.el groups is something that allows for fully arbitrary, unstructured groups based on buffers opened in a current “workspace”—much like the window switch hook you just implemented for activities.el. Hopefully this clarifies where I’m coming from.

And ultimately I think this is more useful for the user as well: if a user shows a buffer in an activity that is technically associated with another project (e.g. I'm working on activities and I want to open a file from ement to see how I did something similar), that buffer then becomes temporarily associated with that activity--and rightly so, because, for that period of time, it was relevant to it. But tomorrow when I resume that activity again, unless I manually switch to that other buffer, it won't be associated with it anymore. It's kind of like automatic garbage collection.

I think this is a perfectly valid approach, but I would say that some users prefer to manually clean up this garbage! And laborious manual removal of buffers from activities lists could often be avoided by quitting an activity without suspending (e.g. by just closing the tab or using activities-kill) once you know your activity’s buffer list is in a state you prefer. Even if it is anathema to you, I’m optimistic that activities.el has the potential to support both approaches.

Thanks again!

[hpfr]

To clarify my thoughts by contrasting them with gcv’s:

I agree that the ability to make a “blank” activity is not particularly necessary when you can just open a new tab and call activities-new once all the visible buffers are related to your activity. You could also go further by hooking tab creation and activity creation together, but I agree with the default approach of not coupling tabs to activities—it’s nice to still have access to more ephemeral tabs.

Although the user may decide to have multiple perspectives share a buffer, any behavior that results in a buffer "leaking" into another perspective is a bug. Adding and removing buffers from perspectives are important operations.

I don’t think adding is particularly important to me (the current window-configuration-change-hook-based implementation seems sufficient), particularly because you can kill the activity without saving once it is in a preferred state as I mentioned previously, but removing would definitely be necessary for me. That said:

But I have no objection to adding a list of predicate functions, similar to the anti-save-predicates, which would preclude a buffer from being added to an activity's buffer list.

Now that I think about it, this would probably help reduce the manual labor associated with managing activity buffer lists even further, so I’m on board with it!

[hpfr]

One more thing for @gcv: if you do want tabs to align directly with workspaces (automatically create new ones as blank, no separate -new command), you might prefer https://github.com/mclear-tools/tabspaces

[gcv]

I don't need tab integration at all. It's nice, of course, and maybe I could get used to it. But Perspective doesn't have tabs and works fine without it (though someone asked me to add support when tab-mode was added to Emacs in the 27 or 28 release).

Making a blank activity by opening a new tab and then a new activity: I think that works, but I'd have to write a wrapper command to automate doing two actions in one step.

On the subject of buffer management: I need the ability to remove a buffer from an activity/perspective manually. If one was added accidentally but belongs in another activity/perspective, for example. I also absolutely need the ability to persist the buffer list to disk so that state is preserved across Emacs sessions.

I looked into Bufler, and it's definitely cool, but I also don't want to write rules for grouping buffers. That a buffer was opened in an activity/perspective is all I care about. Maybe an Activities+Bufler integration mode could be used to automate that behavior in Bufler?

To reiterate, I'm not pushing for any features to get added to this project. It would be cool if it became the modern, slicker replacement for Perspective, but it certainly doesn't have to happen. Activity currently offers a very different UX, but I've also spent about 10 years using Perspective almost daily, so I have a lot of mental and muscle memory attached to its workflow assumptions.

[hpfr]

I don't need tab integration at all. It's nice, of course, and maybe I could get used to it. But Perspective doesn't have tabs and works fine without it (though someone asked me to add support when tab-mode was added to Emacs in the 27 or 28 release).

Ah, that may be why you were wondering about the difference between resume and switch. activities.el associates one activity with a frame or a tab; it doesn’t manage its own list of live activities like Perspective does. If you were to open more frames (or tabs with activities-tabs-mode), you would see that switch only targets activities open in frames (or tabs).

[alphapapa]

I fully agree with trying to keep packages orthogonal and “good citizens”; that’s why I didn’t make this request before, as I assumed it would be out of scope. But from my perspective at least, now that activities-buffer-list and activities-switch-buffer exist, the scope of the package has already expanded to (optionally) include managing a list of buffers beyond the window configuration. So now, rather than polluting the package with a separate concern, serializing this list would make it a more complete solution for its implicit scope. I completely understand if you disagree though—I can only hope that this comment and others like it from folks like @gcv will live in the back of your mind as you continue to iterate on the package in its early days :D.

Certainly. :)

I can’t speak for gcv, but I don’t think what I’m proposing would conflict with these properties. Suspending would just serialize more buffers, and resuming would just load them in the background and restore activities-buffer-list. And this behavior would be behind an option.

Well, I can imagine that being useful, so I'm willing to consider it. I might explore coding it myself, but I have a lot going on right now, so patches welcome, also.

The idea of having to manually add or remove buffers from a list is anathema to me. More than that, I don't think the user should need to care whether a buffer is associated with one activity or another.
(I wrote bufler to group buffers programatically; whether it will find some form of integration with activities is yet to be seen. Probably activities needs to gain some more hooks so that other packages like bufler can integrate with it.)

Regarding bufler, I think my first read of the README gave me the impression that this package was meant as a successor to both burly and bufler, but on second look I see that that only applied to burly and the bufler-workspace extension specifically. So I took another look at bufler. At least for me, I am not interested in setting up predefined rules for grouping buffers. project.el is sufficient for 80% of that, and the additional complexity of setting up custom grouping functions could only take me another 10% further or so anyway.

FWIW, Bufler's default groups are designed to be generally useful, so the user needn't write any. For example, it groups buffers by project, whether they're special/hidden, major mode, etc. I think you would likely find it useful as-is (e.g. if you want to periodically see what buffers are open and clean them up, it's much easier when they're grouped smartly).

I find that the best complement to to the highly structured project.el groups is something that allows for fully arbitrary, unstructured groups based on buffers opened in a current “workspace”—much like the window switch hook you just implemented for activities.el. Hopefully this clarifies where I’m coming from.

Also, Bufler supports that: manually placing buffers into ad-hoc "workspace" groups with a keystroke. (I know the readme is large, so it's not easy to get a quick understanding of everything it does.) If you ever try it, feel free to send feedback.

I think this is a perfectly valid approach, but I would say that some users prefer to manually clean up this garbage! And laborious manual removal of buffers from activities lists could often be avoided by quitting an activity without suspending (e.g. by just closing the tab or using activities-kill) once you know your activity’s buffer list is in a state you prefer. Even if it is anathema to you, I’m optimistic that activities.el has the potential to support both approaches.

Well, if that's something that some users want, I'm willing to consider adding it. Here are some steps I can think of for the development process:

• Probably, first would be to add a slot to the activities-state struct for storing the buffer list (being careful to add it at the end, so as not to invalidate any existing serialized structs--I think that's safe, but we'll want to test to be sure).
• Serialize/deserialize that buffer list (existing code just needs to be plugged in to it).
• Add functionality to the activities-list to view and edit the buffer lists.
• Add an activities-buffer-list-anti-predicates option which would prevent buffers from being added to buffer lists.

Probably this would live on a feature branch for testing for a week or two, then on master for a week or two, and then it could go into a stable release.

[hpfr]

Thanks for taking the time to read my screed!

Also, Bufler supports that: manually placing buffers into ad-hoc "workspace" groups with a keystroke. (I know the readme is large, so it's not easy to get a quick understanding of everything it does.) If you ever try it, feel free to send feedback.

Perhaps I should bite the bullet and try it out then. It looks rather substantial for my needs, but looks can be deceiving.

patches welcome

Here are some steps I can think of for the development process

Yeah, I really need to get my copyright assignment ducks in a row. I’ve been meaning to revisit my email setup before then; this may be the impetus I need to take care of that.

[alphapapa]

@gcv

I don't need tab integration at all. It's nice, of course, and maybe I could get used to it. But Perspective doesn't have tabs and works fine without it (though someone asked me to add support when tab-mode was added to Emacs in the 27 or 28 release).

I use and like tab-bar-mode, but I intend to support a frame-based workflow equally, as much as possible (though I don't promise to personally test it as extensively).

Making a blank activity by opening a new tab and then a new activity: I think that works, but I'd have to write a wrapper command to automate doing two actions in one step.

This brings to mind another idea I've had for a while: to rename the activities-new command to activities-define (i.e. the command would define the current configuration as an activity). Doing so would free up the name activities-new to be a command to make a new frame/tab and name it as an activity. What do you think about that idea?

On the subject of buffer management: I need the ability to remove a buffer from an activity/perspective manually. If one was added accidentally but belongs in another activity/perspective, for example. I also absolutely need the ability to persist the buffer list to disk so that state is preserved across Emacs sessions.

Fair enough. I'm willing for those features to exist in activities as long as the implementation and UI are decently clean. :) I might prefer that it be offered as a minor mode that could be disabled by users who don't need those features. Would that suit your needs?

I looked into Bufler, and it's definitely cool, but I also don't want to write rules for grouping buffers. That a buffer was opened in an activity/perspective is all I care about. Maybe an Activities+Bufler integration mode could be used to automate that behavior in Bufler?

The default rules should be generally useful. Most users won't need to write their own.

At the moment, the challenge for grouping buffers by activity is that buffers aren't strictly associated with activities. We could iterate over activities' buffer lists to see whether a buffer is present in one, but it may also be present in another's, and Bufler as-designed shows a buffer in a single group.

However, if we do end up with something like activities-buffers-mode, that would only allow a buffer to be associated with a single activity, it would mean that grouping buffers by activity would be as simple as:

(bufler-defauto-group activity
  (cl-loop for activity
           in (cl-remove-if-not #'activities-activity-active-p
                                activities-activities)
           when (memq buffer (activities-activity-buffers activity))
           return (activities-activity-name activity)))

To reiterate, I'm not pushing for any features to get added to this project. It would be cool if it became the modern, slicker replacement for Perspective, but it certainly doesn't have to happen. Activity currently offers a very different UX, but I've also spent about 10 years using Perspective almost daily, so I have a lot of mental and muscle memory attached to its workflow assumptions.

Sure. I'm not necessarily trying to replace those other packages, more like to offer my own vision of something similar that meets my needs, while also being flexible and extensible enough to meet others'. And my vision is not firmly defined, so I hope that users will help me shape it as well.

[gcv]

@alphapapa:

rename the activities-new command to activities-define (i.e. the command would define the current configuration as an activity). Doing so would free up the name activities-new to be a command to make a new frame/tab and name it as an activity. What do you think about that idea?

That sounds great.

I'm willing for those features to exist in activities as long as the implementation and UI are decently clean. :) I might prefer that it be offered as a minor mode that could be disabled by users who don't need those features. Would that suit your needs?

Yes. To use the Vertico analogy again, several important features live in non-core minor modes, and it works well. There's a bit of a learning curve at configuration time, but it's not important in the end.

[jdtsmith]

I’m not sure how much of this has yet been implemented other than the new blank slate activities-new. For buffers, I prefer “automatic buffer garbage collection” but would also use the activity-specific buffer switch (I’d likely add a category in consult-buffer).

How about combining these: let the user configure an activities-buffer-expire-time (in days). On resume, auto-remove any activity buffers, aside from those soon to be showing or in the default view, that haven’t been accessed in an activity window for at least that many days. A kind of graceful garbage collection.