-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Too many ideas #3
Comments
Hi JD,
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 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.
Please see the
Yeah, I noticed that when testing with my
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. :)
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
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 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.
Haha, it was named just Well, thanks very much for your feedback. Please keep it coming! |
Thanks for your thoughts. Ahh I missed this!
Seems fine to me.
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).
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. |
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)))) |
Yes, my Burly library: https://github.com/alphapapa/burly.el 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, I also use Burly.el in |
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. |
That was the idea, so I'm glad to hear that it seems that way to others. :) |
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. |
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 useproject.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).Some ideas from my first 10min of usage below (too many, but take it as the sign of real interest it represents ;):
Frame-wrapping
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 adviseactivities--switch
to do this, but I wonder if there are other uses for a list of custom variables that will be dynamically bound aroundmake-frame
(e.g. anactivities-make-frame-variables
alist)?Automatic Updates and Updating the Default State
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.Frame title
It's nice to see activity name in the frame title. But
set-frame-name
is a heavy hammer and removes anyframe-title-format
customizations the user has done. It's easy for such a user to add an:eval
section toframe-title-format
to mention the frame's activity name (if any), but then we need some way to inhibitset-frame-name
.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.
Bookmark support for processes?
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.
Dream feature
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.Bonus point
Bonus point for the best symbol name I've ever seen:
activities-activity-active-p
.The text was updated successfully, but these errors were encountered: