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

Add action for Quick Fix and key binding for Suggestions #17502

Merged
merged 9 commits into from
Jul 17, 2024

Conversation

carlos-zamora
Copy link
Member

@carlos-zamora carlos-zamora commented Jul 2, 2024

Adds a keybinding to open the quick fix menu, if one is available. When the action is used, we also open up the button (if it was collapsed) because that looks nice.

The showSuggestions action is bound to ctrl+shift+period by default to align with VS' "quick actions" feature and VS Code's "quick fix" feature. This was chosen over binding to quickFix because it's more helpful. The quick fix button is a route for users that prefer to use the mouse. If users want to add a keybinding to activate the quickFix button, they can do that now.

This PR also performs a bit of miscellaneous polish from the bug bash. This includes:

  • the suggestions UI now presents quick fixes first
  • scrolling may result in the button being drawn in the wrong place
    • The bug was tracked down this line: TermControl::CursorPositionInDips() --> _core.CursorPosition() --> Terminal::GetViewportRelativeCursorPosition(). The mutable viewport there does not update when the user scrolls. Thus, the button would be drawn on the same position on the screen even though we scrolled. To fix this, I include the _scrollOffset in the calculation. The only other place this function is used is with the suggestions UI, which does not update the UIs position as we scroll (but if we're interested in doing that, we can now).

Closes #17377

@@ -637,6 +638,7 @@
{ "keys":"ctrl+shift+p", "id": "Terminal.ToggleCommandPalette" },
{ "keys":"win+sc(41)", "id": "Terminal.QuakeMode" },
{ "keys": "alt+space", "id": "Terminal.OpenSystemMenu" },
{ "keys": "ctrl+period", "id": "Terminal.QuickFix" },
Copy link
Member Author

Choose a reason for hiding this comment

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

The quickFix action is bound to ctrl+period by default to align with VS' "quick actions" feature and VS Code's "quick fix" feature.

@zadjii-msft funny enough, I feel like openSuggestions would be better suited here. Especially since the suggestions UI loads quick fixes automatically. Maybe we want ctrl+period to be used for openSuggestions instead?

Also, we're in a weird spot rn. Quick fixes are behind a feature flag so idk if it makes sense to bind this just yet. Happy to remove changes to this file, just want some clarity on the plan here.

CC @DHowett

Copy link
Member

Choose a reason for hiding this comment

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

hard veto binding just ctrl+anything. Ctrl alone is reserved for a modifier for the CLI application to use.

I'm probably biased, so I probably need to recuse myself from answering if it should be quickFix or showSuggestions

Copy link
Member Author

Choose a reason for hiding this comment

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

(In case you're curious) Found that "ctrl+period" is used for "repeat the last command" in nano, so yeah, we need a different keybinding.

Changed to "ctrl+shift+period".

The questions above still stand though. How about long-term we do...

  • ctrl+shift+period --> quick fix
  • alt+shift+period --> suggestions
    Just wanna make sure I don't claim a keybinding you were planning to claim later.

Copy link
Member Author

Choose a reason for hiding this comment

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

Discussed a bit during today's bug bash. Here's the leading proposal rn:

  • default kbd opens suggestions UI (source=all)
  • clicking QF button --> open suggestions UI

As we add more quick fixes (i.e. actual winget suggestions, non-snippets, etc.) and non-snippet suggestions, we can revisit this and change it.

Copy link
Member

@lhecker lhecker left a comment

Choose a reason for hiding this comment

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

(Aside from the question in your comment, LGTM.)

@@ -637,6 +638,7 @@
{ "keys":"ctrl+shift+p", "id": "Terminal.ToggleCommandPalette" },
{ "keys":"win+sc(41)", "id": "Terminal.QuakeMode" },
{ "keys": "alt+space", "id": "Terminal.OpenSystemMenu" },
{ "keys": "ctrl+period", "id": "Terminal.QuickFix" },
Copy link
Member

Choose a reason for hiding this comment

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

hard veto binding just ctrl+anything. Ctrl alone is reserved for a modifier for the CLI application to use.

I'm probably biased, so I probably need to recuse myself from answering if it should be quickFix or showSuggestions

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Jul 2, 2024
@zadjii-msft zadjii-msft added this to the Terminal v1.22 milestone Jul 2, 2024
@carlos-zamora
Copy link
Member Author

carlos-zamora commented Jul 2, 2024

Quick Fix feedback from bug bash

  • Sometimes the flyout only opens on the 2nd click on the button

    • ...and only closes on the 2nd click into the terminal
    • This seems related to the tooltip because moving the cursor into the button and clicking it super quickly doesn't cause the issue
    • EDIT: looks like this is a consistent thing with the first time the button appears (regardless of tooltip). Potentially a loading issue? Nah... x:Load was removed :/
    • EDIT 2: Not sure how to even approach this one. We don't have a Click handler. The flyout is defined directly in the XAML as a part of the button. The only thing I can think of is that this is a side effect of populating the flyout menu in the Opening() event, but the context menu doesn't have that problem, I believe. Thoughts?
  • When you open the tooltip with the action, we don't expand the bubble. We should expand the bubble.

  • When the contents scroll (text prints), the button doesn't change position upwards

    • EDIT: having trouble reproing this Repro'd by generating output, then resizing the window down then up (to create a scrollback). Turns out the fix was deep inside the code. Updated the PR body to describe the fix since it's in a bit of a weird place.
  • [Screen Reader] QF kbd --> "pop up window"

  • [Screen Reader] Should we add "use kbd to open" to the "quick fix available" notification?

    • EDIT: we need the action map to be able to get the key binding, but we don't have access to that in the TermControl. Not sure if it's that valuable. Marking as resolved unless somebody else pushes for it (since I filed this one).
  • We should put quickfixes in the suggestions UI first

  • this:
    image

    • EDIT: should be prevented by
      if (vkey == VK_RETURN && !_inAltBuffer())
      {
      // Treat VK_RETURN as a new prompt,
      // so we should clear the quick fix UI if it's visible.
      if (_pfnClearQuickFix)
      {
      _pfnClearQuickFix();
      }
      . Pressing "Enter" to run "vim" should clear the quick fix menu.

@carlos-zamora carlos-zamora self-assigned this Jul 12, 2024
Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

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

I'll approve but maybe we swap that action around in post

@carlos-zamora carlos-zamora changed the title Add a keybinding for Quick Fix Add action for Quick Fix and key binding for Suggestions Jul 16, 2024
@carlos-zamora carlos-zamora added this pull request to the merge queue Jul 16, 2024
Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

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

2/9

src/cascadia/TerminalApp/AppActionHandlers.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalControl/TermControl.cpp Outdated Show resolved Hide resolved
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jul 16, 2024
@DHowett DHowett removed this pull request from the merge queue due to a manual request Jul 16, 2024
@DHowett
Copy link
Member

DHowett commented Jul 16, 2024

I'm bumping this from the merge queue - it took me all of four seconds to find a resource leak 😄

@@ -3920,7 +3940,7 @@ namespace winrt::Microsoft::Terminal::Control::implementation
const auto viewportBufferPosition = rd->GetViewport();
const auto cursorBufferPosition = rd->GetCursorPosition();
rd->UnlockConsole();
if (cursorBufferPosition.y < viewportBufferPosition.Top() || cursorBufferPosition.y > viewportBufferPosition.BottomExclusive())
if (cursorBufferPosition.y < viewportBufferPosition.Top() || cursorBufferPosition.y > viewportBufferPosition.BottomInclusive())
Copy link
Member

Choose a reason for hiding this comment

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

what's this change do?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is an extension of the fix for scrolling may result in the button being drawn in the wrong place.

From some testing, there were some scenarios where the button would be drawn on the bottom left corner of the terminal. The "last visible line of text" would be cut off by the window, so the renderer wouldn't draw the text. But XAML would still draw the button. This didn't seem right to me, so I made this change.

@@ -1597,12 +1597,13 @@ void Terminal::ColorSelection(const TextAttribute& attr, winrt::Microsoft::Termi
}

// Method Description:
// - Returns the position of the cursor relative to the active viewport
// - Returns the position of the cursor relative to the visible viewport
til::point Terminal::GetViewportRelativeCursorPosition() const noexcept
Copy link
Member

Choose a reason for hiding this comment

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

who else uses this, and are they impacted by this change?

Copy link
Member Author

Choose a reason for hiding this comment

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

Already did the research. 😉 Here's the relevant stuff from the PR body:

  • scrolling may result in the button being drawn in the wrong place
    • The bug was tracked down this line: TermControl::CursorPositionInDips() --> _core.CursorPosition() --> Terminal::GetViewportRelativeCursorPosition(). The mutable viewport there does not update when the user scrolls. Thus, the button would be drawn on the same position on the screen even though we scrolled. To fix this, I include the _scrollOffset in the calculation. The only other place this function is used is with the suggestions UI, which does not update the UIs position as we scroll (but if we're interested in doing that, we can now).

@DHowett
Copy link
Member

DHowett commented Jul 16, 2024

Scrolling behavior:

I removed this from the commit message because individual commits inside a PR get destroyed when it is squashed.

@microsoft-github-policy-service microsoft-github-policy-service bot removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jul 17, 2024
@DHowett DHowett merged commit 1999366 into main Jul 17, 2024
18 of 20 checks passed
@DHowett DHowett deleted the dev/cazamor/quick-fix-kbd branch July 17, 2024 22:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a key binding to open Quick Fix
4 participants