Feedback

[psionic-k]

Sorry for this immense lack of effort. Writing my initial impressions, while fresh and ignorant.

1. There needs to be an activities-save command that explicitly only updates the persisted state of the current activity and leaves others alone
2. Separate the intentionally saved durable state and the automatically saved live-updating state. Use "set" and "save" semantics. The activities-mode should "set" the live updating state while "save" should be more durable. This way, if I get too far off of what that activity actually is, I can get back to what it was intended to be. Both "set" and "save" states should persist, but independently.
3. I have anxiety about the minor mode. I want to ignore buffers that return t for any function in a list so I can filter out my usual carousing. Ignore buffers that belong to other activities but not the current activity.
4. An activity could count as a buffer in completions, though I'm not sure if I want to do this from the completions side or by having activities provide completions. When I go to change buffer, my bookmarks, activities, and buffers should all be able to live in one completion list

I did not look in depth. My thoughts reflect first impressions.

Resuming an activity will create a new frame but using my default frame alist instead of copying the current frame. Since my frame almost never matches the default while setting up for screencaps etc, I wind up with frames spawning when I just want to re-use the existing one.

[alphapapa]

Hey, thanks for the feedback. Your initial impressions are valuable.

1. There needs to be an activities-save command that explicitly only updates the persisted state of the current activity and leaves others alone

This could be done, but the idea is for this to be automated; the user shouldn't have to think about manually persisting the last-used state. That's what activities-mode is for, to do so with an idle timer.

The activities-mode timer calls activities-save-all, which saves all active activities' last-used states. It could be modified to only save the current one, but I think that would be a mistake, because it could easily lead to other activities' states not being saved, depending on the user's sequence of actions.

2. Separate the intentionally saved durable state and the automatically saved live-updating state. Use "set" and "save" semantics. The activities-mode should "set" the live updating state while "save" should be more durable. This way, if I get too far off of what that activity actually is, I can get back to what it was intended to be. Both "set" and "save" states should persist, but independently.

This is already the case. Each activity has a default state, which is defined (and re-defined) with activities-new, and a last-used state, which is saved automatically by activities-mode, etc. An activity may be reverted to its default state with activities-revert, or by calling activities-resume with a prefix argument.

3. I have anxiety about the minor mode. I want to ignore buffers that return t for any function in a list so I can filter out my usual carousing. Ignore buffers that belong to other activities but not the current activity.

Yes, please see the option I just added yesterday, activities-anti-save-predicates. If any of those return non-nil, the activity's last-used state is not saved.

Filtering out certain buffers (i.e. saving the activity's state, but ignoring certain buffers) is a similar but slightly different idea. It would be a bit more complex to implement, but it could be useful (e.g. if a window is displaying an unrestorable buffer, like an ERT results buffer, the window's previous-buffers list could be looked at to find the last-displayed buffer that is restorable, and it could be saved instead). However, I'm not sure yet if the complexity and edge cases would be worth it, so I think I'll let the anti-save-predicates option play out for a while before trying other solutions.

4. An activity could count as a buffer in completions, though I'm not sure if I want to do this from the completions side or by having activities provide completions. When I go to change buffer, my bookmarks, activities, and buffers should all be able to live in one completion list

That's surely a useful idea (I still use a Helm command that offers a variety of recent items, including buffers, recent files, files in the current project, recent Org headings, bookmarks, etc). However, I think its scope is outside of activities itself; rather, it should be, e.g. a source added to a Helm or consult command. (I'd be glad, of course, to host some example code that could be plugged in appropriately.)

Resuming an activity will create a new frame but using my default frame alist instead of copying the current frame. Since my frame almost never matches the default while setting up for screencaps etc, I wind up with frames spawning when I just want to re-use the existing one.

I would be glad if you would chime in on #4, where we're trying to decide the best way to handle this. I use activities-tabs-mode exclusively, so my workflow doesn't involve single-purpose frames, so I don't know what the best solution to using frames is. I can imagine that a user might sometimes want to load an activity into a new frame, and sometimes into the current frame, overwriting its current configuration. I'll be glad to support both, appreciating your help to design the most intuitive solution.

Thanks.

[psionic-k]

previous-buffers list could be looked at to find the last-displayed buffer

How about filtering the new state and merging it with the old state? This would allow valid updates to move forward while ignoring invalid updates. Invalidating a buffer shouldn't leave an empty window. If any old buffer is available, it should be used.

	Window-1	Window-2	Window-3
Revert	Old-Buffer-A	Old-Buffer-B	Old-Buffer-C
Current	Old-Buffer-C	Invalid	Old-Buffer-B
Auto-Save	Old-Buffer-C	Old-Buffer-A	Old-Buffer-B

The example in the table is realistic for me Frequently when working on a project, the same several buffers trade windows like musical chairs along with 1-2 irrelevant buffers showing up until I need a relevant one again.

I imagine you're already having to handle cases where a file no longer exists.

on #4, where we're trying to decide the best way to handle this

I'm in the cohort of people who only use one frame and no tabs. display-buffer-alist and split-window-preferred-function do most of the work for me. I mostly only use 2-3 windows, always balanced. My preference is to never make frames.

Without using tabs or frames:

1. I don't have any natural grouping mechanism to restore more than one buffer or window at a time.
2. I would need to be pretty strict about updating automatically since most of my changes are irrelevant to the starting point

Perhaps not using activities-mode and only explicitly saving is the right move for me.

if a window is displaying an unrestorable buffer

The really common case for users like me is instead to have switched to an irrelevant buffer. Since I'm switching to irrelevant buffers almost all the time and I don't have a natural grouping mechanism, activities would form valuable abstractions that allow switching all of the windows and all of the buffers, a very fine complement to my default filthy manner of use. However, because my manner of use will remain filthy, either i need really strict (probably keyed on project) update rules or just to never update automatically. I think there's your key advice for new users.

[jdtsmith]

An activity may be reverted to its default state with activities-revert, or by calling activities-resume with a prefix argument.

The more I think about this the more I think a standalone command for updating the default state is better, for discovery. I appreciate the desire to keep the command footprint low, but it's a bit hard to discover how to do this.

[alphapapa]

How about filtering the new state and merging it with the old state?

I don't know what that would mean. Each window state is atomic. (The only mutation we do is to add the activity-state with the bookmark records, and replace buffer objects with buffer names, so they can be serialized.)

What would it mean to merge two states? (As well, I'm doubtful that the complexity of trying to merge parts of two window states would be worth the trouble.)

This would allow valid updates to move forward while ignoring invalid updates.

I don't know what you mean about valid/invalid updates or invalidating a buffer.

Invalidating a buffer shouldn't leave an empty window.

There are only two alternatives when a buffer can't be restored: show a buffer with the error message (which the user can kill and ignore), or try to use a heuristic to choose another buffer to be displayed.

If any old buffer is available, it should be used.

I guess that depends on what "any old buffer" means. In my experience with Burly and Bufler, having an unexpected buffer displayed tends to be confusing to the user; if they expect buffer A to be shown, but instead they get shown buffer Z that just happens to be open in Emacs at that moment, they will perceive that as a bug and report it. It seems better to show a buffer with a useful error that helps the user understand the problem; then the user can just choose another buffer or revert to the default state.

Window-1 Window-2 Window-3
Revert Old-Buffer-A Old-Buffer-B Old-Buffer-C
Current Old-Buffer-C Invalid Old-Buffer-B
Auto-Save Old-Buffer-C Old-Buffer-A Old-Buffer-B

The example in the table is realistic for me Frequently when working on a project, the same several buffers trade windows like musical chairs along with 1-2 irrelevant buffers showing up until I need a relevant one again.

The "musical chairs" thing is certainly true for me; that's what reversion is intended for. (Beyond that, I think winner-mode handles simple window-configuration history within an Emacs session.)

I imagine you're already having to handle cases where a file no longer exists.

Yes, that's where the error buffer is shown, e.g.:

on #4, where we're trying to decide the best way to handle this

I'm in the cohort of people who only use one frame and no tabs. display-buffer-alist and split-window-preferred-function do most of the work for me. I mostly only use 2-3 windows, always balanced. My preference is to never make frames.

Without using tabs or frames:

1. I don't have any natural grouping mechanism to restore more than one buffer or window at a time.

So IIUC that means that you don't want to have access to multiple activities at once, and that you want resuming an activity to overwrite the current frame's window configuration?

2. I would need to be pretty strict about updating automatically since most of my changes are irrelevant to the starting point

The new activities-anti-save-predicates option can be used that way. Beyond that, reversion to the default state is the intended solution to that.

Perhaps not using activities-mode and only explicitly saving is the right move for me.

Well, I did make it optional on purpose, but I didn't envision that disabling it would be necessary in normal usage. But, sure, if you don't want to automatically save activity states when Emacs is idle, but only when switching activities, then disabling the mode will accomplish that. (Note that disabling it will remove it from kill-emacs-hook as well.)

if a window is displaying an unrestorable buffer

The really common case for users like me is instead to have switched to an irrelevant buffer. Since I'm switching to irrelevant buffers almost all the time and I don't have a natural grouping mechanism, activities would form valuable abstractions that allow switching all of the windows and all of the buffers, a very fine complement to my default filthy manner of use. However, because my manner of use will remain filthy, either i need really strict (probably keyed on project) update rules or just to never update automatically. I think there's your key advice for new users.

Yes, this is the nature of the problem, all these transient (not Transient.el) buffers that are only used and useful for a moment, ones that shouldn't or couldn't be restored when resuming an activity. I'm expecting that the anti-save-predicates will help with that. We could also consider having a list of major modes whose buffers should not be preserved (and possibly a way to determine that automatically depending on whether the mode seems to support bookmark). And in the case of a buffer which shouldn't be preserved/restored, we could try to choose an eligible buffer in a window's previous buffers list.

[alphapapa]

it's a bit hard to discover how to do this.

If only users would read the manual, where it's mentioned at least twice... :) But I'll consider having a command for it. Thanks.

[psionic-k]

having a command

I second a need for at least one command. activities-save is what I need to avoid any anxiety about clobbering all my other activities while just wanting to change one activity's persisted state.

I started reading your replies, but my language was as an outsider looking in, not as someone who understands the internals and implementation. Sorry, my reply is incomplete for now.

and that you want resuming an activity to overwrite the current frame's window configuration?

Yes.

I could have some use for live updating, but on an ephemeral basis or persisted independently of what is persisted for activites-revert. I could see switching into an activity and then popping. I would want to return to where I was in that case, not the revert state.

[alphapapa]

having a command

I second a need for at least one command. activities-save is what I need to avoid any anxiety about clobbering all my other activities while just wanting to change one activity's persisted state.

I could have some use for live updating, but on an ephemeral basis or persisted independently of what is persisted for activites-revert. I could see switching into an activity and then popping. I would want to return to where I was in that case, not the revert state.

I feel like you're almost wanting more than two persisted states. Am I wrong?

[jdtsmith]

it's a bit hard to discover how to do this.

If only users would read the manual, where it's mentioned at least twice... :) But I'll consider having a command for it. Thanks.

I can't complain about this because I make the same point for many packages of mine ;). But you do have the worthy goal of "almost nothing to learn". In terms of what would make intuitive sense (to "guess" how to do this) and not add commands, I mentioned in another issue allowing activities-new to overwrite default.