Streamline interaction

[jdtsmith]

I instinctively expected to be able to make a new activity if I enter a new name with activities-resume (possibly with a y/n prompt). And if I activity-new and re-use an existing name, I'd expect to be prompted y/n to update the default saved value of that known activity.

[alphapapa]

I instinctively expected to be able to make a new activity if I enter a new name with activities-resume (possibly with a y/n prompt).

Can you explain a bit more about that? I don't understand the concept of "resuming" something that hasn't been made or defined yet. For example, if you haven't booted up your PC yet, you can't "resume" it; you have to "suspend" it to sleep mode first. Or for a more general concept of an activity, the idea of resuming something implies that it had previously existed and been active. I don't understand the idea that resuming something is the same as creating it.

And if I activity-new and re-use an existing name, I'd expect to be prompted y/n to update the default saved value of that known activity.

Yeah, I think that would be a reasonable change. The prefix argument could still be used to update its default state without prompting.

Thanks.

[jdtsmith]

I instinctively expected to be able to make a new activity if I enter a new name with activities-resume (possibly with a y/n prompt).

Can you explain a bit more about that? I don't understand the concept of "resuming" something that hasn't been made or defined yet.

I think of it like switch to buffer. Existing buffer? Here you go. New buffer mentioned? Happy to make that for you. In this way a 2 command interface is quite possible.

For example, if you haven't booted up your PC yet, you can't "resume" it; you have to "suspend" it to sleep mode first. Or for a more general concept of an activity, the idea of resuming something implies that it had previously existed and been active. I don't understand the idea that resuming something is the same as creating it.

Perhaps my confusion here is between "switch to" and "resume" activity. To me those are redundant. Imagine if you had a different command to create a non-existing buffer vs. switching to one that exists. Inconvenient.

[alphapapa]

I instinctively expected to be able to make a new activity if I enter a new name with activities-resume (possibly with a y/n prompt).

Can you explain a bit more about that? I don't understand the concept of "resuming" something that hasn't been made or defined yet.

I think of it like switch to buffer. Existing buffer? Here you go. New buffer mentioned? Happy to make that for you. In this way a 2 command interface is quite possible.

So I guess -switch could switch to a new frame/tab with a copy of the previous window configuration (or optionally a clean slate)?

For example, if you haven't booted up your PC yet, you can't "resume" it; you have to "suspend" it to sleep mode first. Or for a more general concept of an activity, the idea of resuming something implies that it had previously existed and been active. I don't understand the idea that resuming something is the same as creating it.

Perhaps my confusion here is between "switch to" and "resume" activity. To me those are redundant. Imagine if you had a different command to create a non-existing buffer vs. switching to one that exists. Inconvenient.

Yes, the reason I added -switch was to allow switching to an active activity separately from the list of all previously saved activities (which could grow large over time).

[jdtsmith]

I see, so "switch" is for the "active sub-list of possible activities". That makes good sense (in fact it explains what being an "-active" activity means I guess).

If I "switch" to a non-existent activity, I'd just expect to be asked if I'd like to create that as a new activity using the current set of buffers/windows etc, since this is so how so many "switch to this" things work in emacs. As in No such activity. Create xyz as a new activity using the current frame configuration? Y/[N].

[alphapapa]

Yeah, maybe we'll do that.

[alphapapa]

v0.5 has a number of changes now, and I'm still not sure what the best thing to do about these ideas is, so I'm extending this issue to v0.6. Please continue to offer feedback as you have it. Thanks.

[jdtsmith]

OK. I still grope around to re-save the default state when I want to update it. A M-x activities-update would really help avoiding a trip to the docs. Then I reach for activities-new, which helpfully offers a default of the current activity, but if you accept that default, complains Activity named "foo" already exists, so it's kind of a useless default ATM.

I don't always know I want to update the default state before I call activities-new, so it makes sense to defer that choice until afterwards. The default would be useful if instead of erroring it offered a y/n choice to Update default state for activity "foo"? [y]/n. But honestly a separate update command (in addition?) might be more discoverable/memorable, and easier to bind to your own key.

For me, the key verbs are resume/revert/update/new, in that order of frequency, so having update relegated to secondary sub-command status feels unnatural.

One more idea if you don't like prompting or extra commands: what about having a prefix key to activities-revert update the default state for the current activity? Reason? Reverting to default and updating that default seem highly thematically related.

[alphapapa]

I'm considering an "update" command, but I'm not sure about the name.

What if activities-new were named activities-define? And then the prefix argument would be used to have it "redefine" an existing activity. Would that help with memorability?

One more idea if you don't like prompting or extra commands: what about having a prefix key to activities-revert update the default state for the current activity? Reason? Reverting to default and updating that default seem highly thematically related.

They are related, yes, but I don't like that idea, because it would mean that the prefix argument would invert the command from loading a state to saving a state, which I think could be confusing.

[karthink]

What if activities-new were named activities-define? And then the prefix argument would be used to have it "redefine" an existing activity. Would that help with memorability?

Re: memorability. How about just activities-set, like bookmark-set?

A couple of thoughts on the prefix-arg behavior of activities-new.

Instead of throwing a user-error when trying to overwrite an existing activity:

activities-new: Activity named ".emacs.d" already exists

you could prompt for confirmation: An activity named ".emacs.d" already exists. Set anyway? (y/n). If it's renamed to activities-set, then a prompt like this makes sense -- it's just setting with confirmation.

[jdtsmith]

I think new is good as is. For update, perhaps overwrite or freshen? Honestly if new prompted me y/n for an existing activity, I'd probably just use that.

[karthink]

I think new is good as is. For update, perhaps overwrite or freshen?

I suggested renaming activities-new to activities-set under the assumption that no new command (activities-update) would be needed.

In any case the prefix-arg behavior of activities-new, implying unconditional setting of the activity, can continue to exist alongside a y-or-n-p prompt when called without a prefix-arg.

[alphapapa]

I suppose my theory about about the new command is weird: it would be confusing if it were used to redefine an activity's default state, because that would not be making a new activity--but if it required a prefix argument to do so, that would be okay, because it would be explicit. (I know it doesn't really make sense.)

That's why I thought about changing the name to activities-define, because that doesn't necessarily denote making a new one, but just defining one; and definitions can be redefined, like with defvar.

I feel like it could also reduce some confusion about whether the command would switch to a new frame/tab: since it doesn't necessarily denote "newness," it could make sense to define an activity as the current frame/tab's configuration.

But this is the hard part, because we all have different ideas about what these words should mean in these contexts based on our varied experiences.

set is certainly a Lispy term, but it also seems vague to me in this context: does it "set an activity as the current one"? Does it "set the current configuration as an activity"? Does it "set something about an activity"?

I wish we could get by without having to make a command just to redefine an activity's default state. I'm trying to follow Emacs's idioms as much as I can, and if one thinks of, e.g. files, there's not one command to write a file for the first time and a separate command to overwrite it--there's just save-buffer and write-file, which only differ in that the latter command always prompts for a filename, whereas the former saves to the buffer's existing file name if it has one.

By that logic, I should use activities-save, and maybe that's not so bad. But at the same time, I don't want the user to have to think in terms of file operations--that part is meant to be abstracted--so that's why I like the idea of "defining" and "redefining" an activity.

So here's another idea, partially regurgitated but modified according to feedback: What if activities-new were renamed to activities-define, and attempting to define an existing activity prompted to overwrite its default state without requiring a prefix argument? Then the prefix arg could be used to skip the prompt.

[jdtsmith]

And I’ve used a switch-to-buffer analogy (where new if not existing is builtin). Maybe none of these is perfectly apt.

What if activities-new were renamed to activities-define, and attempting to define an existing activity prompted to overwrite its default state without requiring a prefix argument? Then the prefix arg could be used to skip the prompt.

Sounds like a winner to me.

[jdtsmith]

PS: if you want to keep the command landscape as small as possible,activities-switch seems a bit superfluous to me, since it’s like resume, but for the subset of activities-already-activated-this-session. So a prefix to resume makes good sense there.

[alphapapa]

PS: if you want to keep the command landscape as small as possible,activities-switch seems a bit superfluous to me, since it’s like resume, but for the subset of activities-already-activated-this-session. So a prefix to resume makes good sense there.

Are you suggesting to remove activities-resume and to require the user to C-u activities-switch to resume an inactive activity?

[jdtsmith]

I'd do it the other way around: resume is the main function, but if you want the list narrowed to active activities only, add a prefix arg. If we get marginalia and age-based sorting (#20), most people probably won't care about switch since actives will be at the front of the list.

[alphapapa]

Ok, I'll think about it.