Naturally support both frames and frames with tabs

[shipmints]

This discussion started in #102 which included @jdtsmith and @alphapapa and now moved here. I am attempting to copy the core of the ideas and concerns here for discussion.

The current activities code base is bifurcated, frame-only, and tabs-only which itself is built on top of the frame-only code through many function overrides that lead to duplication of code and policy. This makes it harder to diagnose issues, harder to introduce new features, and generally harder to understand.

It also makes it impossible in its current form to support both frame-oriented style and tab-oriented style of use simultaneously. I prefer a combination work flow with certain frames containing a no-tab activities activity tied to the frame and some frames having activities-aware tabs. I'd guess the ability to handle both workflows is the default assumption of most new users and may be the cause of some confusion as they try to get the best of both worlds. Supporting both is also useful for multi-monitor or multi-desktop users who want frames from the same Emacs session in more than one place and this includes users of emacs-mac which affords more native frame experience to MacOS users.

In the current activities implementation, to get both styles (but with limitations on frame behavior), one is forced to pick tab-mode with one hidden tab. For frame-only users, they currently give up ever having the option to use tabs in alternative frames, being stuck in frame-only mode.

One idea to make this possible it to piggyback on the tab-bar-mode frame-parameter 'tab-bar-lines which is set to 1 when a frame has tab-bar enabled, and 0 otherwise.

Users can control in which frames tab-bar-mode is enabled. This seems like a nice feature for activities to use to determine if it should have frame policy or tab policy frame-by-frame.

I suppose one would still need winner-mode in frames without tab-bar-mode enabled. In frames tab-bar-mode, one could use tab-bar-history-mode which provides winner-mode behavior. This setting is depicted below.

I'd be happy to help with implementing such an approach. It seems a natural method to leverage in Emacs 28+.

P.S. Here's a snippet for people to look at to understand how one gets an emulated frame-orientation with activities-tab-mode enabled:

(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
  (setq 'tab-bar-show nil)
  ;; BUG: there's a race-condition using customize before the initial
  ;; frame is completely set up, themed, and otherwise configured 
  ;; within one's startup code. Feel free to invoke customize after
  ;; set up is complete to alter tab-bar-show frame by frame.
  ;; (customize-set-variable 'tab-bar-show nil)
  (setq tab-bar-history-limit 25) ; default 10
  )

[jdtsmith]

Just to be concrete about what I meant when I said you'd still end up with the same amount of code and complexity, take activities--switch as an example. We have two flavors at present:

Frame

(defun activities--switch (activity)
  "Switch to ACTIVITY.
Select's ACTIVITY's frame, making a new one if needed.  Its state
is not changed."
  (if (activities-activity-active-p activity)
      (select-frame (activities--frame activity))
    (pcase activities-resume-into-frame
      ('current nil)
      ('new (select-frame (make-frame `((activity . ,activity)))))))
  (unless activities-saving-p
    ;; HACK: Don't raise the frame when saving the activity's state.
    ;; (I don't love this solution, largely because it only applies
    ;; when not using `activities-tabs-mode', but it will do for now.)
    (raise-frame))
  (when activities-set-frame-name
    (set-frame-name (activities-name-for activity))))

tab-bar

(defun activities-tabs--switch (activity)
  "Switch to ACTIVITY.
Selects its tab, making one if needed.  Its state is not changed."
  (if-let ((tab (activities-tabs--tab activity)))
      (tab-bar-switch-to-tab (alist-get 'name tab))
    (tab-bar-new-tab))
  (tab-bar-rename-tab (activities-name-for activity)))

So a new unified activities--switch would need to:

1. Determine if you are in frame-mode or tab-mode for the current frame.
2. If in frame-mode:
   • see if the activity is active on a tab, in this frame or another.
   • if it is, pull it out as a single-tab frame, e.g. with tab-bar-detach-tab.
   • set that frame to be in single-tab frame-mode.
3. If in tab-mode:
   • if the activity is active in a tab on some other frame, pull it into this frame with tab-bar-move-tab-to-frame.
4. If not active:
   • if in tab mode: make a new tab in this frame
   • if in frame mode: make a new frame and put it in "single tab mode."
   • open the activity in the newly created tab(/frame).

I can fairly well envision that this would be at least as complicated as the two separate functions we have now, of which only one is active at a time. It seems to me a small additional bit of logic in an advice to activities-tabs--switch could get you what you want: e.g. if in "frame-mode", override tab-bar-new-tab to be some hypothetical tab-bar-new-tab-in-new-frame-in-single-tab-mode prior to calling activities-tabs--switch.

[shipmints]

Yep there will be those cases. Perhaps some unification makes policy setting and feature implementations easier if it's all in one place? Maybe this is just me being new to the code.

While your point may not argue in support of unifying the code, it doesn't negate the point/need about supporting both modes at the same time. Perhaps using the method I described to tell if a frame is tabbed or not.

Thank you for taking the time and effort to participate in the discussion. Your own Emacs contributions are clever. Gonna grab indent-bars as soon as it hits ELPA/MELPA. eglot-booster maybe, too.

[shipmints]

I edited the topic to make it clearer that I (perhaps we) prioritize simultaneous support for both frames and tabs and unifying the code base might just be a nice-to-have or just be impractical. Supporting both modes can be done with the existing code structure for sure.

[alphapapa]

IMO what you're really wanting is a complete redesign of how activities interact with frames and tabs. I think it would be helpful to start by thinking in terms of 2 or 3 use cases or workflows in which we describe the end result the user wants, and then think about how to design the functionality to enable the user to do so in a flexible, simple way.

For example:

1. User wants to open 3 activities as tabs in a single frame.
   a. Sub-case: Open them in an existing frame.
   b. Sub-case: Open them in a new frame.

   In order to do this, we first need a way to let the user select multiple activities. This could be done with something like completing-read-multiple on top of existing code, or we could use some kind of name-prefix or regexp matching, or we could implement a way to define groups of activities or sub-activities (see e.g. this and this). I think the latter would be more useful, because if I were to want to open the same set of activities regularly, I wouldn't want to have to tediously multi-select them each time.

2. User wants to open those same 3 activities each in its own frame.

   Now we have to consider how to let the user control whether a set of activities is opened in a frame, or in multiple frames (and which ones?). What I definitely don't want is a multitude of commands with triply-hyphenated names, where the user has to select just the right one from a list of them each time. Prefix arguments are slightly less undesirable, but too many of them, or too wide a variety of them, is almost as bad, and perhaps more confusing.

   We also need to consider whether some kind of "open this group in a frame" or "open this group in multiple frames" configuration should be "baked in" to an activity-group or parent-activity, or whether that should be done on-demand when the user operates on them. I tend to think that having some of it baked in would be useful, because most of the time the user will do the same thing every time, but we'd also need to provide a way to override the baked-in setting; and we also need to figure out how the user can make such settings (I don't want users having to do setq on data structures or set per-activitiy customization options manually).

3. User wants to either a) always use one activity per frame, or b) always use a tab per activity in the current frame (i.e. the status quo).

   In other words, users who currently like the existing paradigm, where either activities-tabs-mode is enabled or isn't, shouldn't have to relearn the UI to keep using it as-is. Any new functionality we add should extend, not mutate, existing workflows (within reason; I don't rule out very minor changes).

IME the hardest part is designing this kind of functionality to be useful, simple, and comprehensible. Once the design is done, writing the code is straightforward, just a matter of looking up the APIs and fixing edge cases.

[jdtsmith]

I agree that "first, do no harm" should absolutely be a guiding principle here. Activities will thrive based on its simplicity and easy mental model.

[alphapapa]

Other discussion also happened in #78 and #84.

Please consolidate further discussion here. Thanks.

[hapst3r]

After reading the different discussions on the matter, I'd like to advocate the idea of activity groups (with sub-activities) which has been somewhat discussed in #84 (the use case described there is exactly how I currently use emacs frame/tab-constellations). If I am not misunderstanding the other suggestions, the notion of activity groups (as per #84 (comment)) could be a good approach which allows adding on top of existing functionality without requiring a redesign from the ground up.

EDIT: as to implementation, I had something in mind which appears more simple than what I have read in prior discussions. In my current workflow, an activity group consists of one frame with several tabs, each of which is a sub-activity of the project I am currently working on. What is part of this project (the bundled sub-activities) might change over time, which means I delete tabs I deem no longer relevant, while others persist and new ones are created.

In my mind, a command could be written that creates an activity group out of those tabs within the current frame. There is no "reparenting" of sub-activities, an activity group can be altered by changing the (contents of) tabs and overwriting its prior state.

I believe such a limited implementation would leave the current code largely untouched, simply adding another "module" to extisting functionality. It could even be its own supplemental package with a narrow scope.

[alphapapa]

I agree that, probably, something like "activity groups" could be implemented on top of existing functionality. If nothing else, it would be a good way to experiment with new ideas.