Quake mode: Add support for reserved tabs #14044

@deoradh commented on GitHub (May 30, 2021):

Potentially related to https://github.com/microsoft/terminal/issues/766, https://github.com/microsoft/terminal/issues/9992

@deoradh commented on GitHub (May 30, 2021): Potentially related to https://github.com/microsoft/terminal/issues/766, https://github.com/microsoft/terminal/issues/9992

claunia commented

@dag03tsc commented on GitHub (May 31, 2021):

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.

@dag03tsc commented on GitHub (May 31, 2021): 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.

claunia commented

@deoradh commented on GitHub (May 31, 2021):

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.

@deoradh commented on GitHub (May 31, 2021): 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.

claunia commented

@dag03tsc commented on GitHub (May 31, 2021):

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.

@dag03tsc commented on GitHub (May 31, 2021): 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.

claunia commented

@deoradh commented on GitHub (May 31, 2021):

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.

@deoradh commented on GitHub (May 31, 2021): 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.

claunia commented

@dag03tsc commented on GitHub (May 31, 2021):

... 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?

@dag03tsc commented on GitHub (May 31, 2021): > ... 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?

claunia commented

@deoradh commented on GitHub (May 31, 2021):

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

@deoradh commented on GitHub (May 31, 2021): Uniqueness of identifiers means those tabs would be distinguishable. It would be a syntactic error in the profile to permit collisions.

claunia commented

@dag03tsc commented on GitHub (Jun 1, 2021):

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.

@dag03tsc commented on GitHub (Jun 1, 2021): > 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.

claunia commented

@deoradh commented on GitHub (Jun 1, 2021):

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

@deoradh commented on GitHub (Jun 1, 2021): 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

claunia commented

@deoradh commented on GitHub (Jun 1, 2021):

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

@deoradh commented on GitHub (Jun 1, 2021): 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

claunia commented

@dag03tsc commented on GitHub (Jun 1, 2021):

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 @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.

@dag03tsc commented on GitHub (Jun 1, 2021): 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 @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.

claunia commented

@deoradh commented on GitHub (Jun 1, 2021):

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

@deoradh commented on GitHub (Jun 1, 2021): it has nothing to do with 9992, and I'd appreciate it if you'd stop hijacking other people's suggestions.

claunia commented

@dag03tsc commented on GitHub (Jun 1, 2021):

I'm so sorry but you clearly misunderstood my intentions 'cause I've never meant to hijack anything from anyone.
My only intention is to collaborate with the community in bringing new features aboard and fixing bugs.

In addition, I always give the credit to whom it belongs, as you can see in the first line of the last comment I've written in 9992.
Obviously, I've linked this suggestion to give it visibility and raise it, not to pull it down or to hijack it in any way, and I'm really sorry if I offended you in any way with that misunderstanding.

I really look for this feature to become available so everyone can benefit from it! 😊 👍

@dag03tsc commented on GitHub (Jun 1, 2021): I'm so sorry but you clearly misunderstood my intentions 'cause I've never meant to hijack anything from anyone. My only intention is to collaborate with the community in bringing new features aboard and fixing bugs. In addition, I always give the credit to whom it belongs, as you can see in the first line of the last comment I've written in 9992. Obviously, I've linked this suggestion to give it visibility and raise it, not to pull it down or to hijack it in any way, and I'm really sorry if I offended you in any way with that misunderstanding. I really look for this feature to become available so everyone can benefit from it! 😊 👍

claunia commented

@zadjii-msft commented on GitHub (Jul 6, 2021):

Okay so this issue sounds to me like two separate requests:

"I want a global hotkey that combines a globalSummon and a switchToTab into a singular action/keypress"
I want to be able to pin tabs (#5969)

Focusing on just the first half of the request (as discussion on the second is probably best saved for #5969) - I'm not sure there's a simple way to express that. Given the possible scenarios that a user might want for that, IMO, the mentally easiest model is to just press two keybindings. win+`, ctrl+alt+2 is a little bit of keyboard gymnistics, but you could always rebind actions so that it's easier. If you want to get weird, you could bind:

{ "keys": "win+alt+1", "command": { "action": "globalSummon" } },
{ "keys": "win+alt+2", "command": { "action": "globalSummon" } },
{ "keys": "win+alt+3", "command": { "action": "globalSummon" } },
{ "keys": "win+alt+4", "command": { "action": "globalSummon" } },
//...

(to bind all of win+alt+N to "summon the window"),

Then, do something like win+alt+2, ctrl+alt+2 to not have to move that many fingers.

@zadjii-msft commented on GitHub (Jul 6, 2021): Okay so this issue sounds to me like two separate requests: * "I want a global hotkey that combines a `globalSummon` and a `switchToTab` into a singular action/keypress" * I want to be able to pin tabs (#5969) Focusing on just the first half of the request (as discussion on the second is probably best saved for #5969) - I'm not sure there's a simple way to express that. Given the possible scenarios that a user might want for that, IMO, the mentally easiest model is to just _press two keybindings_. <kbd>win+`</kbd>, <kbd>ctrl+alt+2</kbd> is a little bit of keyboard gymnistics, but you could always rebind actions so that it's easier. If you want to get weird, you could bind: ```jsonc { "keys": "win+alt+1", "command": { "action": "globalSummon" } }, { "keys": "win+alt+2", "command": { "action": "globalSummon" } }, { "keys": "win+alt+3", "command": { "action": "globalSummon" } }, { "keys": "win+alt+4", "command": { "action": "globalSummon" } }, //... ``` (to bind all of win+alt+N to "summon the window"), Then, do something like <kbd>win+alt+2</kbd>, <kbd>ctrl+alt+2</kbd> to not have to move that many fingers.

claunia commented

@ghost commented on GitHub (Jul 11, 2021):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Jul 11, 2021): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.

claunia commented

@deoradh commented on GitHub (Jul 11, 2021):

{ "keys": "win+alt+1", "command": { "action": "globalSummon" } },
{ "keys": "win+alt+2", "command": { "action": "globalSummon" } },
{ "keys": "win+alt+3", "command": { "action": "globalSummon" } },
{ "keys": "win+alt+4", "command": { "action": "globalSummon" } },
//...

That looks like a reasonable compromise.

@deoradh commented on GitHub (Jul 11, 2021): > ```js > { "keys": "win+alt+1", "command": { "action": "globalSummon" } }, > { "keys": "win+alt+2", "command": { "action": "globalSummon" } }, > { "keys": "win+alt+3", "command": { "action": "globalSummon" } }, > { "keys": "win+alt+4", "command": { "action": "globalSummon" } }, > //... > ``` That looks like a reasonable compromise.

claunia commented

@zadjii-msft commented on GitHub (Jul 12, 2021):

Awesome, thanks for following up!

@zadjii-msft commented on GitHub (Jul 12, 2021): Awesome, thanks for following up!

claunia commented