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 NextSearchMatch and PreviouSearchMatch actions #8522

Closed
wants to merge 2 commits into from
Closed

Add NextSearchMatch and PreviouSearchMatch actions #8522

wants to merge 2 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Dec 8, 2020

Summary of the Pull Request

This PR adds new action so that users can search next an previous serching results.

References

PR Checklist

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

@ghost ghost added Area-Settings Issues related to settings and customizability, for console or terminal Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Task It's a feature request, but it doesn't really need a major design. Priority-3 A description (P3) Product-Terminal The new Windows Terminal. labels Dec 8, 2020
@ghost
Copy link
Author

ghost commented Dec 8, 2020

_searchBox->TextBox().Text().empty() in TermControl.cpp seems doesn't work. As a result terminal will crashes if there isn't any text in the TextBox.

_Search(_searchBox->TextBox().Text(), true, false);
}

void TermControl::SearchPreviousMatch()
Copy link

Choose a reason for hiding this comment

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

Would TermControl::SearchPrevMatch() be a better name as would match all the other occurences of "Prev"?

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.

So this is kinda the same deal as the Command Palette keybindings PR, right? If the user has the Find dialog open, the user won't be able to use these keybindings successfully right? We'd need to do a keymap lookup to see if the keypress is mapped to one of these actions, right?

Comment on lines 80 to 73
else if (e.OriginalKey() == winrt::Windows::System::VirtualKey::N)
{
if (shiftDown && ctrlDown)
{
_SearchHandlers(TextBox().Text(), !_GoForward(), _CaseSensitive());
}
e.Handled(true);
}
else if (e.OriginalKey() == winrt::Windows::System::VirtualKey::K)
{
if (shiftDown && ctrlDown)
{
_SearchHandlers(TextBox().Text(), _GoForward(), _CaseSensitive());
}
Copy link
Member

Choose a reason for hiding this comment

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

Why are N and K being special cased here? What if someone unbinds those keys?

@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Dec 15, 2020
@zadjii-msft zadjii-msft assigned ghost and unassigned zadjii-msft Dec 15, 2020
@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Dec 15, 2020
@ghost
Copy link
Author

ghost commented Dec 21, 2020

@zadjii-msft I used TerminalPage::_KeydownHandler(). Please review!

@zadjii-msft
Copy link
Member

Hey sorry that this one has been sitting for so long. It must have been lost in my mailbox right as we went on holiday. I'll take a spin through the code now.

/cc @Don-Vito since you've been working in this area recently too

@zadjii-msft zadjii-msft assigned zadjii-msft and unassigned ghost Jan 19, 2021
Copy link
Contributor

@Don-Vito Don-Vito left a comment

Choose a reason for hiding this comment

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

@Hegunumo, @zadjii-msft - I have few questions 😊

@@ -224,6 +224,26 @@ namespace winrt::Microsoft::Terminal::TerminalControl::implementation
}
}

void TermControl::SearchNextMatch()
{
if (!_searchBox)
Copy link
Contributor

Choose a reason for hiding this comment

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

@Hegunumo, @zadjii-msft - product question: if the search box is collapsed and we invoke "search next" binding, shouldn't we open a search box and try to search with the last needle (if exists)?

Copy link
Member

Choose a reason for hiding this comment

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

Okay, so I maybe mentioned this in #8588 - Maybe we should! Or we don't necessarily need to open the search dialog, but we could just move to the next needle.

It's a good idea, and something we should probably stick in #3920 as a follow up to (both these PRs)

@@ -938,10 +958,21 @@ namespace winrt::Microsoft::Terminal::TerminalControl::implementation

void TermControl::_KeyHandler(Input::KeyRoutedEventArgs const& e, const bool keyDown)
{
if (e.OriginalKey() == VirtualKey::Enter)
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you please document here why aren't we handling Enter in the terminal control? I guess it works, but I am not sure why 😊

return;
}

if (keyBindingSearch)
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you please document your logic here as well? If we searched with key binding then we should ignore the next key?

Copy link
Member

Choose a reason for hiding this comment

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

Curious. If we use the keybinding to invoke this action, then on the keyDown, we'll select the text. Then on the key_up_, we'll dismiss the selection.

Copy link
Member

Choose a reason for hiding this comment

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

Okay this is definitely tricky, and I don't know what a good solution is.

The action is either invoked:

  • with a keybinding, in the TermControl::_KeyHandler(true, ...) method
  • by some other magic way (command palette)?

So if it happened on a keydown, we do need to not dismiss the selection on the next keyup. Weird. I wonder how this worked in the keyboard-selection implementation. Wouldn't that have hit the same problem? Paging @carlos-zamora to see if he can here. Am I just being daft? Is there an obvious way to create a selection via action and have it not dismiss on the keyup?

Copy link
Member

Choose a reason for hiding this comment

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

Derp. I can't read.
#3758 (comment)

We need to do this for #3758 so I'm just gonna do it here anyways

// If the current focused element is a child element of searchbox,
// we do not send this event up to terminal
if (_searchBox && _searchBox->ContainsFocus())
if (_searchBox && _searchBox->ContainsFocus() && _searchBox->TextBox().Text().empty())
Copy link
Contributor

Choose a reason for hiding this comment

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

Please update the documentation of the condition as you have restricted it.

Here as well I am not sure I understand why do we need the restriction. I mean now if the key event got here but the searchbox is focused are we sure it is OK to proceed? Cannot it result with sending a character to a terminal?

Optimally we don't need to check the ContainsFocus here at all. Instead we should make sure that SearchBoxControl handles the relevant key routed events.

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.

Okay, I'm a little confused why some of these cases are needed. Comments might help explain. I'm worried that our keyboard handling for the TermControl/SearchBox is terribly convoluted, and you're running into that. So it is probably not your fault that this doesn't really make a lot of sense. At the same time, I'd rather not make it worse 😬

@@ -2541,6 +2544,18 @@ namespace winrt::TerminalApp::implementation
termControl.CreateSearchBoxControl();
}

void TerminalPage::_GoForward()
{
const auto termControl = _GetActiveControl();
Copy link
Member

Choose a reason for hiding this comment

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

Should these be

if (const auto termControl{ _GetActiveControl() })
{
    termControl.SearchNextMatch();
}

to make sure termControl isn't null?

Comment on lines +961 to +964
if (e.OriginalKey() == VirtualKey::Enter)
{
return;
}
Copy link
Member

Choose a reason for hiding this comment

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

Why is this needed?

Comment on lines +973 to 977
if (keyBindingSearch)
{
keyBindingSearch = false;
return;
}
Copy link
Member

Choose a reason for hiding this comment

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

This feels wrong to me. I know currently, actions are only triggerable with the keyboard, but theoretically, they might be invokable through other UI elements. Are we just trying to prevent the keys from being duplicated here?

// If the current focused element is a child element of searchbox,
// we do not send this event up to terminal
if (_searchBox && _searchBox->ContainsFocus())
if (_searchBox && _searchBox->ContainsFocus() && _searchBox->TextBox().Text().empty())
Copy link
Member

Choose a reason for hiding this comment

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

Why is this _searchBox->TextBox().Text().empty() clause needed?

Comment on lines +288 to +289
{ "command": "nextSearchMatchKey", "keys": "ctrl+shift+n" },
{ "command": "prevSearchMatchKey", "keys": "ctrl+shift+k" },
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure how the team feels about adding these to the default keybindings - @DHowett thoughts?

@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Jan 19, 2021
@Don-Vito
Copy link
Contributor

@Hegunumo - it looks that @zadjii-msft and I wrote exactly the same comments 🤦 I am not removing mine, as they probably contain some more info, put please ignore the ones that seem double.

@Don-Vito
Copy link
Contributor

Don-Vito commented Jan 25, 2021

@zadjii-msft - is it only me or Hegunumo user is shown as a deleted user? 😢

@DHowett
Copy link
Member

DHowett commented Jan 26, 2021

Unfortunately, yes :( i was just putting together the selfhost announcement and the thanks section and found that I couldn’t correlate his username any longer.

@zadjii-msft
Copy link
Member

Oh RIP. They had some great contributions. I'll inherit these abandoned PRs and help drive them across the finish line, since they're fundamentally good.

@zadjii-msft
Copy link
Member

I'm moving this to #8917. Hopefully we can get this across the finish line ☺️

ghost pushed a commit that referenced this pull request Feb 18, 2021
This PR is a resurrection of #8522. @Hegunumo has apparently deleted
their account, but the contribution was still valuable. I'm just here to
get it across the finish line.

This PR adds new action for navigating to the next & previous search
results. These actions are unbound by default. These actions can be used
from directly within the search dialog also, to immediately navigate the
results. 

Furthermore, if you have a search started, and close the search box,
then press this keybinding, _it will still perform the search_. So you
can just hit <kbd>F3</kbd> repeatedly with the dialog closed to keep
searching new results. Neat!

If you dispatch the action on the key down, then dismiss a selection on
a key up, we'll end up immediately destroying the selection when you
release the bound key. That's annoying. It also bothers @carlos-zamora
in #3758. However, I _think_ we can just only dismiss the selection on a
key up. I _think_ that's fine. It _seems_ fine so far. We've got an
entire release cycle to futz with it.

## Validation Steps Performed
I've played with it all day and it seems _crisp_.

Closes #7695 

Co-authored-by: Kiminori Kaburagi <yukawa_hidenori@icloud.com>
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 Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Task It's a feature request, but it doesn't really need a major design. Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something Priority-3 A description (P3) Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Please add "next search match" and "prev search match" bind-able key for find operations
5 participants