Add Spec for Quick Fix

[carlos-zamora]

Quick Fix will be a new UI surface that allows the user to interact with the terminal and leverage the context of a specific command being executed. This new UI surface will be a home for features like WinGet Command Not Found.

#16599

[zadjii-msft]

I'm a NAK on the TerminalApp layer being the ones to draw this (as someone who's been down that road before)

[zadjii-msft]

accent color is an interesting choice - why that over like, the foreground color? Or yellow from the scheme's color table?

[carlos-zamora]

Personally, I feel like accent color is a good way to signify that the UI is personalized to the user from by the system (vs color scheme colors being a part of the standard theming). Accent colors just pop more, imo.

[carlos-zamora]

@zadjii-msft here's the UI I have from my branch.

Normal version:

Collapsed version:

I did change it so that it's not just based on the "padding". It's a little more complicated than that, but basically we check if the button would "fit" in the gutter (with the icon being a similar size to the buffer font size).

[zadjii-msft]

oh my god it's so cool

[PankajBhojwani]

@zadjii-msft here's the UI I have from my branch.

Looks slick! One question though - is the button supposed to show up on the prompt with the error in it? The GIF shows the button showing up on the next empty prompt line, which IMO is a little unintuitive

[carlos-zamora]

Yup! Intentional to align with VS Code's design. I think it's so that if you had a lot of output, you don't have to scroll all the way back up to get to the quick fix menu.

[PankajBhojwani]

That makes sense! Should the suggestion get input into that empty line then? Like in the image below. (Not sure if that's just a demo bug, just making sure I'm not missing it if it's in the spec!)

[DHowett]

eh, it's probably because of the secret ^C we insert before the command to make sure it doesn't conflict with input the user has already typed

[carlos-zamora]

eh, it's probably because of the secret ^C we insert before the command to make sure it doesn't conflict with input the user has already typed

Yup, exactly that. We're always sending over the ^C for now, which is why we end up getting that blank line. But hopefully sometime in the future (perhaps with shell integration) we won't need to do that always.

I won't block this while i'm out

[zadjii-msft]

as it only appears on the latest prompt

how are we placing that / knowing where a prompt is? I forget - do we emit the osc 9001 at the start of the error message, or the end?

[carlos-zamora]

how are we placing that / knowing where a prompt is?

So, actually, implementation-wise, I'm not really checking for when the next prompt is ready:

It's been working for me so far (** knock on wood **). Any suggestions on a better way to do it?
 

do we emit the osc 9001 at the start of the error message, or the end?

We emit OSC 9001 at the start of the error message.

[zadjii-msft]

I'm a little curious what the shape of this API actually looks like? Is it like,

runtimeclass TermControl {
    // ...
    event Windows.Foundation.TypedEventHandler<TermControl, CommandNotFoundRequestedArgs> CommandNotFound;
    Microsoft.UI.Xaml.Controls.CommandBarFlyout QuickFixMenu { get; };
}

(maybe not a CommandBarFlyout - something that's appropriate. Flyouts are hard)

...

// TerminalPage.cpp
term.CommandNotFound({ this, &TerminalPage::DoAWingetLookupForCommand });
term.QuickFixMenu().Opening([this](auto&& sender, auto&& /*args*/) {
     this->AddQuickFixesToMenu(term.QuickFixMenu());
});

[carlos-zamora]

Here's a bit of an overview:

1. OSC 9001; CmdNotFound; <missingCmd> bubbles up from Terminal --> TermControl --> TermApp

// TermControl.idl
event Windows.Foundation.TypedEventHandler<Object, SearchMissingCommandEventArgs> SearchMissingCommand;

// EventArgs.idl
runtimeclass SearchMissingCommandEventArgs
{
     String MissingCommand { get; };
}

2. TermApp receives the SearchMissingCommand event and does the following:

std::vector<hstring> suggestions;
// populate suggestions with "winget install {}"

auto term = _GetActiveControl();
term.UpdateWinGetSuggestions(single_threaded_vector<hstring>(std::move(suggestions)));
term.ShowQuickFixMenu();

3. Quick Fix button is now displayed. When clicked, we...

term.QuickFixMenu().Opening([weak = get_weak(), weakTerm](auto&& sender, auto&& /*args*/) {
    if (const auto& page{ weak.get() })
    {
        // Stuff the flyout menu with quick fixes we retrieve from the control
        // NOTE 1: we get them from the control via "control.CommandHistory().QuickFixes()" which
       //             returns the list of suggestions from step 2
       // NOTE 2: each menu item also clears the quick fix menu using "ClearQuickFix()" when invoked
        page->_PopulateQuickFixMenu(weakTerm.get(), sender.try_as<Controls::MenuFlyout>());
    }
});

So TermControl.idl ends up exposing the following:

        event Windows.Foundation.TypedEventHandler<Object, SearchMissingCommandEventArgs> SearchMissingCommand;
        Windows.UI.Xaml.Controls.MenuFlyout QuickFixMenu { get; };
        void UpdateWinGetSuggestions(Windows.Foundation.Collections.IVector<String> suggestions);
        void ShowQuickFixMenu();
        void ClearQuickFix();

[PankajBhojwani]

@zadjii-msft here's the UI I have from my branch.

Looks slick! One question though - is the button supposed to show up on the prompt with the error in it? The GIF shows the button showing up on the next empty prompt line, which IMO is a little unintuitive

[zadjii-msft]

I'm picking nits at this point. My only main want is to make sure we can put these on more than just the last row (for shell integration features), but that's a solid vNext problem. Let's get to the code review