Skip to content
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

Bugfix: serialize iterable commands #10373

Merged
1 commit merged into from
Jun 10, 2021
Merged

Conversation

carlos-zamora
Copy link
Member

Summary of the Pull Request

Fixes a bug where top-level iterable commands were not serialized.

PR Checklist

Detailed Description of the Pull Request / Additional comments

  • Command::ToJson:
    • iterable commands deserve the same treatment as nested commands
  • ActionMap:
    • Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.

@carlos-zamora carlos-zamora added the zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. label Jun 9, 2021
@ghost ghost added Area-Settings Issues related to settings and customizability, for console or terminal Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-0 Bugs that we consider release-blocking/recall-class (P0) Product-Terminal The new Windows Terminal. Severity-Blocking We won't ship a release like this! No-siree. labels Jun 9, 2021
@carlos-zamora
Copy link
Member Author

While working on this bugfix, I realized that another bug exists:

{
    "name": "${profile.name}",
    "command": { "action": "newTab", "profile": "${profile.name}" },
    "iterateOn": "profiles"
},
{
    "name": "${profile.name}",
    "commands": [ { "command": "newTab" } ]
}

Here, the settings model exports these commands to the command palette as one entry in the name map (the iterable command). This is wrong though, because really the user is explicitly asking for a command named "${profile.name}".

However, this bug already exists in v1.8, but in a different manifestation.

Here's the encountered behaviors:

  • this PR: iterable command wins
  • v1.8 & main: whichever command is added second wins (in the case above, nested command)
  • expected: no conflict

This bugfix brings us closer to a world where this new bug is fixed. We would need to mess with how we expand commands. But (a) that's too risky for a hotfix and (b) this is a really obscure bug.

@DHowett Thoughts?

@DHowett
Copy link
Member

DHowett commented Jun 10, 2021

@DHowett Thoughts?

I'd say just.. file it and we can move on. 😄

// copy _IterableCommands
for (const auto& cmd : _IterableCommands)
{
actionMap->_IterableCommands.Append(*(get_self<Command>(cmd)->Copy()));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qq: why do we need to keep them separate from the nested commands?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keeping them separate does half of the work for this bug.

Combining them keeps the same buggy behavior from v1.8/main.

@carlos-zamora carlos-zamora added the AutoMerge Marked for automatic merge by the bot when requirements are met label Jun 10, 2021
@ghost
Copy link

ghost commented Jun 10, 2021

Hello @carlos-zamora!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 9294ecc into main Jun 10, 2021
@ghost ghost deleted the dev/cazamor/tsm/am/iterable-commands branch June 10, 2021 18:25
@DHowett DHowett removed the zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. label Jul 7, 2021
DHowett pushed a commit that referenced this pull request Jul 7, 2021
## Summary of the Pull Request
Fixes a bug where top-level iterable commands were not serialized.

## PR Checklist
* [X] Closes #10365
* [X] Tests added/passed

## Detailed Description of the Pull Request / Additional comments
- `Command::ToJson`:
   - iterable commands deserve the same treatment as nested commands
- `ActionMap`:
   - Similar to how we store nested commands, iterable commands need to be handled separately from standard commands. Then, when generating the name map, we make sure we export the iterable commands at the same time we export the nested commands.

(cherry picked from commit 9294ecc)
@ghost
Copy link

ghost commented Jul 14, 2021

🎉Windows Terminal v1.9.1942.0 has been released which incorporates this pull request.:tada:

Handy links:

@ghost
Copy link

ghost commented Jul 14, 2021

🎉Windows Terminal Preview v1.10.1933.0 has been released which incorporates this pull request.:tada:

Handy links:

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Settings Issues related to settings and customizability, for console or terminal AutoMerge Marked for automatic merge by the bot when requirements are met Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-0 Bugs that we consider release-blocking/recall-class (P0) Product-Terminal The new Windows Terminal. Severity-Blocking We won't ship a release like this! No-siree.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Saving in the Settings UI breaks "iterateOn"
3 participants