Too many ideas about activities.el

[jdtsmith]

Here's my advice for anyone wanting emacs-mac native tabs for activities:

(advice-add #'activities--switch :around
	      (defun my/activities-in-mac-tabs (orig &rest r)
		(let ((mac-frame-tabbing t))
		  (apply orig r))))

[jdtsmith]

Thanks for your thoughts.

Ahh I missed this!

Call activities-new with a universal prefix argument (C-u C-x C-a n) to redefine an activity’s default state.

Seems fine to me.

Yeah, I noticed that when testing with my makem.sh script, which sets the frame title itself. I'm not sure of the best solution here.

Just a simple config option to avoid set-frame-name would probably be fine, then the user can configure it in the frame title (and you could document a few examples).

In keeping this library as simple as possible, I want to delegate the per-buffer restoration functionality entirely to bookmark. So if there's any functionality that needs to be added to support that, it should probably be done in that kind of shell buffer's major-mode.

Quite sensible. I actually have such a mode I've been working on, and wondered whether bookmark-based state restore would be worth investigating or if you knew of examples.

[jdtsmith]

The only feature idea here worth exploring in the near term is frame-title, and I think that deserves its own issue.

[alphapapa]

Hi JD,

What a breath of fresh air activities is! I've never stuck with any workplace tool because I find them too rigid and far too complex. I also tend to bounce around in my layout quite a bit and they punish me for that. I use project.el but find it confining sometimes (many activities span projects!). I just wanted a simple tool that saves all my relevant state related to some given activity,and restores it easily. activities seems perfect for this; thanks for much for bringing it to life. It's literally a one key interface for me: f10 to jump to an activity, C-f10 to revert the current one (OK two keys).

Thank you for saying that. That's exactly what I've intended to make, a tool that isn't too rigid (like desktop.el) or too complex (like many "workspace" libraries); one that can co-exist with other tools, etc. Despite my best tries, it seems very difficult to communicate this design intention to users--it seems like the only way for anyone to understand is to try it. And I'm glad that you did. :) Feel free to chime in on emacs-devel on the thread, if you like; so far I've seemingly had to argue for its inclusion in GNU ELPA, and a positive review from a user might be helpful in that regard.

I'd like to use frames and not tabs, so I leave (activities-tabs-mode) out, but in reality I'd like to use mac native tabs (which are just frames from emacs' perspective). To do so, I just need to wrap frame-creating code with (let ((mac-frame-tabbing t)).... I could easily advise activities--switch to do this, but I wonder if there are other uses for a list of custom variables that will be dynamically bound around make-frame (e.g. an activities-make-frame-variables alist)?

I expect that some options like that will need to be added, yes. I do want to keep them to a minimum, so I'll probably only add them at users' request or as I need them personally. I want to keep the package as simple as possible, but not more simple than is useful for users' needs.

I'm a little concerned about the automatic activities updating. The reason is that I've found I often "drift away" from an activity, reusing windows to put out some other fire as they pop up. I think I'd prefer to "opt in" to the saving of state. But then on closer look, I see activities-revert is always there, ready to save my bacon and get me back on track when I inevitably mess things up. So that's very comforting.

But then I wonder, how do I update an activity's "default state" when my needs evolve? Just M-x activities-new again, reusing the same name? Do I have to delete it first? Some way to update the default state of the current activity (activities-update-default?) would be nice.

Please see the activites-new command, which says: "With prefix argument, overwrite an existing activity (thereby updating its default state to the current state)." However, I'm not necessarily opposed to adding a command to do this; but I also want to keep the number of commands to a minimum, so it seemed like using a prefix arg for this would make sense. Let me know what you think.

It's nice to see activity name in the frame title. But set-frame-name is a heavy hammer and removes any frame-title-format customizations the user has done. It's easy for such a user to add an :eval section to frame-title-format to mention the frame's activity name (if any), but then we need some way to inhibit set-frame-name.

Yeah, I noticed that when testing with my makem.sh script, which sets the frame title itself. I'm not sure of the best solution here.

It would also be nice if you could see in the frame title that the default activity state has been modified, so a predicate to test for that would be wonderful. This predicate would probably need to compute a "coarse modification" flag, i.e. testing only the most important configuration parameters (buffer list, number of windows, etc.) against their default values. Changing frame size/moving point/etc. shouldn't count as a true change IMO.

Something like that could be done, and would probably be useful, yes. I'm not sure about writing a predicate that excluded such values from its computation; of course it's possible, being software, but the window configuration state object is a deeply recursive and complex object, which would make such a predicate complicated. We'll see. :)

I wonder, does bookmark-based restore allow re-opening existing processes and associated buffers? You could then imagine restoring (remote?) shells with the right virtual environment, etc. with a single key.

As you can probably imagine, you're far from the first user to mention something like this, with regard to my other packages that have similar functionality, like Burly.el and Bufler.el. You're right that it would be very useful--and also that it's up to the bookmark library to handle it. In keeping this library as simple as possible, I want to delegate the per-buffer restoration functionality entirely to bookmark. So if there's any functionality that needs to be added to support that, it should probably be done in that kind of shell buffer's major-mode. (And any of those improvements which could be upstreamed into Emacs itself would benefit everyone, not just users of activities.)

The only dream feature I could imagine for now: often times my activities are 4-6 windows on a large external monitor, but I can "afford" only 3 or so when on my laptop. It would be fantastic if activities had some sort of frame size awareness on invocation/revert. I'm not talking CSS responsive design here, just optional min-width/min-height parameters for a given activity, with several parallel sets available under the same activity name. The appropriate "sub-layout" would be selected when you first load or revert the activity, depending on available size.

I have considered allowing activities to have "sub-states" which could be selected with completion, but in the interest of simplicity, I've decided to forego that for now.

I don't know if automating that kind of feature within activities would be feasible. But I think you could do so in your own configuration with only a few lines of code: just define one activity for the large size, and another for the small one, and define a command of your own to resume one or the other depending on monitor size. It would mean, of course, having to activate that activity with a command other than activities-resume, but you could, e.g. use an Emacs bookmark for it, which can already be used to resume activities, so there would be some overlap.

Beyond that, maybe we can come up with some more ideas to help enable advanced features like that; I'm not necessarily opposed to it, as long as the core functionality can remain simple.

Bonus point for the best symbol name I've ever seen: activities-activity-active-p.

Haha, it was named just activity-active-p, but then I renamed the library from activity to activities, and activities-active-p didn't seem like an accurate name, so...yeah. :)

Well, thanks very much for your feedback. Please keep it coming!

[alphapapa]

I actually have such a mode I've been working on, and wondered whether bookmark-based state restore would be worth investigating or if you knew of examples.

Yes, my Burly library: https://github.com/alphapapa/burly.el activities borrows some code from it. The main problem with Burly is that it's hard to communicate to users what it does. "Activities" seems to help a little bit, but it's still hard.

The other big difference is that Burly encodes window/frame states to URLs (i.e. strings). That's where the name came from: BufferURLy. My idea was that, like a Web page, each buffer ought to have a URL by which its state can be referred to and restored. I found that bookmarks handle the state saving and restoring (for many modes, anyway), and I went ahead with the URL-encoding because that's what I had decided to do. I guessed that maybe users could share URLs to useful window configurations, store them in Org files, etc. I think that could still be done, but I don't know how useful that would be. Anyway, activities state info could also be encoded into a URL-like string if desired, but it has to be done carefully or some encoding issues can crop up (see reports on the Burly repo).

I also use Burly.el in bufler-workspace to save and restore "workspaces". But I'm hoping that activities will be this idea's "final form" (in a broad sense, anyway; it's still in its own early stages). If so, I guess burly would become mostly obsolete. But we'll see.

[jdtsmith]

"Activities" seems to help a little bit, but it's still hard.

That definitely clicked for me. If you can get people to try it for 10s, they will get it instantly. Think ultra simple quick start guide. I suspect some YouTubers will pick it up. It's so easy, there's effectively nothing to learn.

[alphapapa]

It's so easy, there's effectively nothing to learn.

That was the idea, so I'm glad to hear that it seems that way to others. :)

[alphapapa]

The only feature idea here worth exploring in the near term is frame-title, and I think that deserves its own issue.

Yes, please do file an issue for that if you like.