activities-rename in activities-tabs-mode should rename the activity tab immediately

[shipmints]

As it stands, one has to wait for what seems like 5 seconds before the tab name changes after activities-rename. It doesn't seem related to activities-mode-idle-frequency as I set it to 1 second and still had to wait 5. I can see that the mode-line updates immediately, but not the tab bar. It's probably obvious why, but perhaps waking before 5am for the solstice sunrise has addled my brain today.

[alphapapa]

The renaming happens here: https://github.com/alphapapa/activities.el/blob/65bfb6f7f246a66a7b6209096c3a634430323758/activities-tabs.el#L181 And it happens when the auto-save timer goes off, which switches to each activity in turn.

The tricky part about things like this is that we have to have two implementations, one for frames and one for tabs. Maybe it's not so "tricky" as just a bit awkward.

Anyway, thanks, this should indeed be improved.

[shipmints]

May I propose a solution to the two-implementation awkwardness? If we can offer that frame users simply use frames with a single tab and with the tab bar hidden, the implementation could be collapsed. @jdtsmith would have to agree, of course. He's the current voice of frame-only users.

For what it's worth, I'm also a plain frame user and I do this alongside frames with tabs. For vanilla frames with one tab and (customize-set-variable 'tab-bar-show 1) so the tab bar is hidden yet tab-bar-history still works. I don't use winner-mode anymore and simply bind the identical winner keys to tab-bar-history-back and tab-bar-history-forward.

[jdtsmith]

I've heard tell of this "one tab winner replacement" mode but never tried. I actually do use tabs, but not tab-bar tabs. Instead I use native MacOS tabs, as provided by emacs-mac. You can pinch to get a graphical overview of open tabs, rearrange them, drag them from one "frame" to another or into their own frame, etc. They are actually "just frames". But there are plenty of frame users out there, including those who seem to want to replace the activity in a frame rather than span a new frame. I suspect supporting all the various "modes" of manifesting an activity would be roughly the same amount of code whether you split it into two files or not.

[shipmints]

@jdtsmith I'd be grateful if you try out tab-bar-mode with the hidden tab with the setting I suggested. If it turns out transparent enough to you, which I suspect it will be, we'd be able to get a simpler code base with fewer bugs, easier to fix bugs, and easier to add features.

As you probably know, tab bar is a shite name for the feature. It's really a window configuration tool that happens to have optional tabs. If they'd named is better, there'd be less confusion. Your native Cocoa tabs are totally separate matter. I use clover-` to switch among frames on my Mac (I rarely use anything but the keyboard) and I'm totally with you on window-manager conveniences.

It would be easier for me to contribute to a simpler code base and I'm doing my best as it is with the complex implementation. I like this package and the small contributor community here, and I'm grateful for @alphapapa having put this together to begin with and donating his time to us all.

Here's a configuration snippet you might find useful.

(use-package tab-bar
  :ensure nil
  :hook
  (
   (emacs-startup . tab-bar-mode) ; BUG: there is a bug where enabling tab-bar before the frame completes startup hides the minibuffer
   (emacs-startup . tab-bar-history-mode)
   )
  :bind
  (
   ;; match winner-mode keys
   ("C-c <left>" . tab-bar-history-back)
   ("C-c <right>" . tab-bar-history-forward)
   )
  :config
  (customize-set-variable 'tab-bar-show nil)
  (setq tab-bar-history-limit 25) ; default 10
  )

[alphapapa]

@shipmints As nice as it might be to have a simpler implementation, I don't think I'd want to impose a one-tab-per-frame-and-hidden-tab-bar limitation on frame users. One of the principles of this library is to interfere with other features as little as possible.

[shipmints]

I say don't knock it till will we all try it. If the package had started out implemented with a one-hidden-tab-per-frame basis for users that wanted that mode of operation, and with optional additional tabs baked in and ready to go, there'd be little concern today. The configuration burden of setting tabs-mode and not showing the tabs to gain the benefit of window configuration is absolutely no higher than anything else in the Emacs universe, while the maintenance burden seems higher than it otherwise needs to be. (The package can offer to do this configuration if we really want since it's so simple.) While the package is still on the young side seems the time to take these kinds of considerations on board.

Happy to contribute either way, just want to beat this horse until we're sure the multi-modal implementation vs. simpler policies by configuration is a hill for it to die on before it gets too ingrained as the package gains popularity.

[jdtsmith]

Even with the "trick" you'd still need to be frame-aware. New frame or reuse same frame? Loop over all frames or tabs in this frame? Close a frame when suspending an activity?

I don't think there's a magic way to

1. Provide frame support at the current level.
2. Rid yourself of frame commands.

[shipmints]

Agree. I'd like to use both workflows at the same time. No reason to force one or the other. One frame for an email activity with no tabs (visible or otherwise). Another frame for software development with visible tabs (been experimenting with tab-groups and those are a touch broken in activities and I'll file an issue and patch soon). Adding a frame-parameter to frame for frame mode and either nothing or it's complement for tab mode seems like it would work. Then it's a matter of deciding how to configure the policy for each frame at the user level. This is how tab-bar-mode itself knows if it's enabled for a frame or not and it supports both modes simultaneously. activities could piggyback on tab-bar-mode frame parameter called 'tab-bar-lines and not invent something new.

[alphapapa]

@shipmints What you're suggesting seems like a major redesign and refactor. I'm open to discussing it, but it will require being very specific about the details. Please open a Discussion about it, as this issue is for another purpose.

[shipmints]

See #106.