Quake mode: Add support for reserved tabs

Description of the new feature/enhancement

The current quake mode implementation entails a window with a well-known name. This window gets specially handled with regard to summoning: it gets docked and focus mode is turned on. It is otherwise a normal window capable of hosting multiple tabs.

There are existing requests filed for supporting multiple quake mode windows, each with a different profile running. That seems unnecessary given the ability for an existing terminal window to host multiple profiles already. What is lacking is the ability to specify which tab to bring active on summon.

Proposed technical implementation details (optional)

Allow the ability to define reserved tabs by name:

"windows": [
  {
    "name": "_quake",
    "tabs": [
      { "profile": "<guid or name .. not sure which would be better>", "name": "my PS tab" },
      { "profile": "...", "name": "my scratchpad tab" },
      { "profile": "...", "name": "my wolfram tab 1" },
      { "profile": "...", "name": "my wolfram tab 2" },
      { "profile": "...", "name": "org mode" },
      { "profile": "...", "name": "dashboard" }
    ]
  }
]

or, alternatively, add "window" and "tab" names to the existing profile schema, binding them exclusively:

{
    "guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
    "hidden": true,
    "name": "PowerShell",
    "window": "_quake",
    "tab": "my PS tab"
}

Then add an argument to wt.exe that allows specification of the specific tab name to activate (or, if the alternative approach is taken, a profile which has a window and tab name defined). If it is not already live, it will be activated. In this way, hot keys can be defined to summon specific tabs.

On exit or close of any of the named tabs, the tab will remain open, waiting to restart the command in question (immediately, if currently active).

Additional tabs created in the window will follow after the named tabs.

Potentially related to #766, #9992

LGTM.

The first option with guid names seems more flexible but I would replace the tabs object with an startupActions string to enable further launch customization, and maybe add a few more properties.

"windows": [
   {
     "name": "_quake",
     "startupActions": "",
     "alwaysOnTop": true,
   }
 ]

Sadly, that'd made this a duplicate of #9992, and this should be closed 'cause #9992 seems to be a more uniform and flexible approach.

Disagreed: #9992 doesn’t come close to the core request for this, which is the ability to summon the windows *and* switch to a tab with a fixed name. That “and” is critical, as is having a stable identifier for a tab: Doing it by position as initially spawned via a startup action doesn’t work – positions (and titles, as noted in a separate issue) can change, whereas identifiers are constants. This feature request is orthogonal to your suggestion of having startup actions.

Ok, now I see what you mean.

Maybe there should be an additional tab string property inside the window object but what happens when there're two tabs, each one with an instance of the same profile, and both inside the same window?

It'd require some kind of "discrimination keybinding" and/or "tab switcher" applied N times over the exact same profile. Some kind of circular keybinding like the tab switcher's ctrl+tab but with a custom sequence and applied to tabs that share the same profile or something like that but I'm not really sure of its usefulness.

Uniqueness of identifiers is a general presumption about identifiers 😊 This is why I wouldn’t key it off of things like “title”, which is absolutely intended to change. Similarly, I wouldn’t base it on which profile was attached to the particular tab, since there are easy example of needing, say, multiple PS windows. Though you could simply resolve the ambiguity by spinning up a new profile with a slightly different launch command. Defining things window-wise feels easier to think about, but defining things profile-wise is simpler to implement (don’t need to add new entities to the settings model, just a pair of new properties). If defined profile-wise, the presence of these two properties would be sufficient to block traditional instantiation, so we wouldn’t have the issue of two instances of the same tab: WT would explicitly take over and manage the lifecycle of such tabs as I suggest earlier.

... but what happens when there're two instances of the same tab in the same window?

I apologize. I've committed a mistake. I meant two tabs, each one with an instance of the same profile, and both inside the same window.

I'm not really sure I got it right. Do you mean something like the ctrl+alt+f* of some Linux distros? Some predefined launch keybindings targeting some predefined set of windows?

Uniqueness of identifiers means those tabs would be distinguishable. It would be a syntactic error in the profile to permit collisions.

Uniqueness of identifiers is a general presumption about identifiers

Strictly speaking, that's not true.
It's true that some UUIDs may seem unique but it's all about deterministic algorithms with seeds.
I'm not really sure about Microsoft GUIDs but for UUIDs, seeds can be categorized as:

Date & MAC based: v1 and v2.
Pseudo-Random based: v4.
Namespace based: v3 and v5.

You'll clearly see that each one is strictly deterministic, even the Pseudo-Random one, therefore the uniqueness holds if, and only if the seed, or set of seeds, is unique itself; the UUID uniqueness is directly inherited from its seeds uniqueness.

Uniqueness of identifiers means those tabs would be distinguishable.

How'd you prevent collisions while, at the same time, enable a way to know a tab's GUID prior the actual tab's creation?
You'd need to know it before its creation to be able to use it as a CLI parameter, property setting or keybinding.

It would be a syntactic error in the profile to permit collisions.

I'm pretty sure we all agree that a profile is just a pattern of initialization for any tab's pane, therefore it cannot be linked to a single tab or pane. While a pane must always reference one, and only one profile, a profile can be referenced from N panes without restriction; it just make no sense talking about tab collisions within a profile context, 'cause profiles apply to panes, not tabs.

You're not presenting any particular argument against this. This is not a difficult or even novel concept in programming and, honestly, it comes off at grasping for straw men. — Keith J. Farmer

If anything, d, you're demonstrating that you didn't read the suggestion: it is (again) to provide the very names to tabs that would be used in summoning. This is entirely configured by the user, and UUID creation algorithms are irrelevant. — Keith J. Farmer

Mike Griese (@zadjii-msft)

I read your suggestion and I fully understood it, but I'm not sure I've explained myself right.
Please, don´t get me wrong, I just try to be constructive and to debate, not to argue, so I apologize if I offended you somehow.

What you call tab, is actually a collection of panes, and the name of a pane is, in fact, the name of the profile loaded inside it, as well as many other inherited properties like background, tab color, GUID, etc.
When you click over (or focus) a pane, the tab just reflects the properties of the focused pane.

Due to its focus inheritance nature, conceptually, I guess there's no such thing like a tab ID, despite its position, 'cause it's just a simple group of panes created for the sole purpose of easing the navigation, and the properties of each of these pseudo-groups called tabs relays entirely on its currently focused pane.

I see that you'd like to have some kind of unique ID for each tab. You called it name and I called it GUID; let's call it UID (Unique ID).
Maybe a few more properties too. Even a completely new entity definition inside the model like #9992 proposes, but for tabs.
But that's the main reason I called this /dup #9992 , 'cause Mike Griese (@zadjii-msft) asked the community for possible additional properties and this could be one of them.

If you reformulate this suggestion, it mainly asks for adding the next properties inside the window entity that #9992 proposes:

"tabs": {
  "name": string;
  "index": number;
  "panes": {
    "index": number;
    "profile": string;
    "size": number;
    "split": string;
    "splitMode": string;
  }[];
}[];
"defaultTab": string;

As you see, I added a few more interesting properties and enabled managing multiple panes too, but it does not make this a new issue. I'd still consider it as a comment for enhancement to #9992. In fact, that's exactly what I'm going to do right now.

it has nothing to do with 9992, and I'd appreciate it if you'd stop hijacking other people's suggestions.

Awesome, thanks for following up!

.. wait. the compromise I had in mind still begs having tab switching as part of summon. otherwise it's status quo, and nothing is solved. — Keith J. Farmer

…

________________________________ From: Mike Griese ***@***.***> Sent: Monday, July 12, 2021 8:03:50 AM To: microsoft/terminal ***@***.***> Cc: Keith J. Farmer ***@***.***>; Author ***@***.***> Subject: Re: [microsoft/terminal] Quake mode: Add support for reserved tabs (#10279) Closed #10279<#10279>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#10279 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACLMBSBKDPSNYEN4UMKITZDTXL75NANCNFSM45YZWV7Q>.

Sorry, this got lost in my mailbox and I'm just thinking of it again. I'm resurrecting this, because it tracks well with another thread I'm about to file.

Proposal:

tabIndex: Switch to that tab, if there are that many.

Navigation Menu

Repository navigation

Quake mode: Add support for reserved tabs #10279

Description of the new feature/enhancement

Proposed technical implementation details (optional)

8 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Quake mode: Add support for reserved tabs #10279

Description

Description of the new feature/enhancement

Proposed technical implementation details (optional)

Activity

deoradh commented on May 30, 2021

dag03tsc commented on May 31, 2021

deoradh commented on May 31, 2021

dag03tsc commented on May 31, 2021

deoradh commented on May 31, 2021

dag03tsc commented on May 31, 2021

deoradh commented on May 31, 2021

dag03tsc commented on Jun 1, 2021

deoradh commented on Jun 1, 2021

deoradh commented on Jun 1, 2021

dag03tsc commented on Jun 1, 2021

deoradh commented on Jun 1, 2021

8 remaining items

zadjii-msft commented on Jul 12, 2021

deoradh commented on Jul 12, 2021

zadjii-msft commented on Jan 11, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions