Hypothetical activities-update-current-default

[jdtsmith]

I am still missing a simple command to quickly update the default state for the current activity (see #16). I came up with this:

(defun my/activities-update-default ()
    (interactive)
    (if-let ((current (activities-current)))
	(when (y-or-n-p
	       (format "Update default for activity %s with current state? "
		       (activities-activity-name current)))
	  (activities-save current :defaultp t :lastp t)
	  (message "Updated %s default state"
		   (activities-activity-name current)))
      (message "No current activity to update.")))

Which I bind to C-S-<f10>. This works perfectly: updating current activity (if any) after asking permission. I'm certain others would use this feature (and the method to update default would be more visible) if installed as a command.

[alphapapa]

Somehow I've developed the habit of holding down the Ctrl key and pressing u x a n to redefine an existing activity. It works well for me. But I can see how other users would prefer an explicit command. How about this?

(defun activities-redefine (activity)
  "Redefine ACTIVITY."
  (interactive (list (activities-completing-read :prompt "Redefine activity")))
  (activities-new (activities-activity-name activity) :forcep t))

[jdtsmith]

pressing u x a n to redefine an existing activity

You still have to type out the activity name then! This looks good, but I'm not sure why the user wants/needs to select an activity. Only the current activity can be redefined with the current window/buffer config, yes?

[alphapapa]

pressing u x a n to redefine an existing activity

You still have to type out the activity name then!

No, the default name is for the current activity, so you only have to press RET.

This looks good, but I'm not sure why the user wants/needs to select an activity. Only the current activity can be redefined with the current window/buffer config, yes?

Why? The idea is that these commands behave consistently and allow the user to select any activity, defaulting to the current one when there is one.

[jdtsmith]

Ahah... E.g., if you have two closely related activities that share some (/most) buffers. For example, I've thought of using sometimes a convention like foo and foo* activities, for "plain" and "rich" (help, info, shell buffers, etc.) versions of the same activity, which I can switch between.

[alphapapa]

That's an interesting idea.

So do you agree that the command I posted is reasonable to add? Or will it meet your needs?

[jdtsmith]

Yes, I just tried it and it works very well, and would also support the "update this state as something else" foo* style.

It also reminds me that once we get #20 sorted, I want to provide marginalia styling for an activity that includes whether it is current, whether it has been modified from its default state, its buffers/file/window count, the coarse modification age of the associated files (1hr, 1day, 1 week, etc.), and/or possibly some other "last saved" age, if the activity record stores that.

[alphapapa]

Well, I haven't added it yet... :)

[ParetoOptimalDev]

I am still missing a simple command to quickly update the default state for the current activity (see #16). I came up with this:

(defun my/activities-update-default ()
    (interactive)
    (if-let ((current (activities-current)))
	(when (y-or-n-p
	       (format "Update default for activity %s with current state? "
		       (activities-activity-name current)))
	  (activities-save current :defaultp t :lastp t)
	  (message "Updated %s default state"
		   (activities-activity-name current)))
      (message "No current activity to update.")))

Which I bind to C-S-<f10>. This works perfectly: updating current activity (if any) after asking permission. I'm certain others would use this feature (and the method to update default would be more visible) if installed as a command.

This function works great for me and was exactly what I wanted.

[alphapapa]

Since changing activities-new to activities-define, and making activities-new its own command, I'm not sure I want to add an activities-redefine command, because that's now provided by activities-define with a prefix argument.

Let me know what you think.

[jdtsmith]

Hmm I must admit that I don't quite see the value of the new activities-new, vs. just making a new tab, setting it up how I like, and actitivities-defineing it. And I still don't have a way to bind a key to something that "prompts to redefine the current activity", so I still need something like in my initial post. I'm OK maintaining this, but I do suspect others may have a similar need.

[ParetoOptimalDev]

Hmm I must admit that I don't quite see the value of the new activities-new, vs. just making a new tab, setting it up how I like, and actitivities-defineing it.

I agree. @alphapapa is the expected workflow of activities-new that activities-define is always used afterwards? The first time I used activities-new I immediately killed the activity, tried restoring it, then was surprised by message Activity "test" has no last state. Resuming default..

It seems like activities-redefine could be the only necessary function here if the workflow was:

• create a new tab
• set up how you like
• activities-define

Then if you were in an existing activity, activities-define just updates the current.

Not having activities-new though is probably weird from a UX perspective. I think that not having activities-new save the current state is surprising too though.

Curious on your thoughts of the above though.

[alphapapa]

I'm leaning toward expecting users who really need a separate command for that to add something like this to their config:

(keymap-global-set "C-x C-a C-r"
                   (defun ap/activities-redefine ()
                     (interactive)
                     (let ((current-prefix-arg t))
                       (call-interactively #'activities-define))))

I want to keep the number of commands down. So if you don't mind, I'll wait and see if anyone else says that they also need it as a separate command.