Add find all button

[yisibl]

Fixed #14836

[mention-bot]

By analyzing the blame information on this pull request, we identified @Inori and @alexandrudima to be potential reviewers

[msftclas]

Hi @yisibl, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

[msftclas]

@yisibl, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.

Thanks, MSBOT;

[rebornix]

I think we don't modify locaization files ourselves, only touch the English version.

[yisibl]

@rebornix Do you mean that do not modify the localization file? Should I submit a PR to increase localization translation?

[rebornix]

yup, just leave it there, it will be handled by the localization team.

[rebornix]

yup, just leave it there, it will be handled by the localization team.

[yisibl]

Done!
By the way, how do I open a localized UI to vscode after the source code is compiled?

[yisibl]

I removed the localized changes.

[yisibl]

@alexandrudima This can be merge?

[alexdima]

I would like to bring in our UX folks on this, rather than just merging it in and get their advice on how we can add functionality to the find widget without overdoing it.

@stevencl @bgashler1 Can I please get your opinion on this proposal?

[yisibl]

@alexandrudima Thanks!

[stevencl]

I really like the idea. We might consider doing something similar to Visual Studio. Instead of three separate buttons for find next, find previous and find all, VS has a button with a drop down that allows you to select the specific action you want to use. So it would look something like this mockup (showing what the user sees when they click the drop down):

The idea would be that you click on the drop down next to the button to run and then change the command. So if you click Find Previous in the drop down, the button changes to the Find Previous button. If you click Find All, the button changes to the Find All button etc.

@bgashler1 might have some other, better ideas. I haven't spoken with him about this today.

[yisibl]

@stevencl

I am more inclined to the 100% width of the search box, and the height is adaptive. Now the search box is too short, and the preparation of the code when you may often need to search for a relatively long code fragment. If it is a 100% width search box, then there is no need to fold(drop down) the buttons.

Sublime Text:

---

By the way, usually the focus of our vision is on the left, especially when full screen writing code, usually we will set up more than 80 characters automatically wrap. So now the search box aligned to the right, I think the user experience is not good.

Anyway I expect the next version can be added to find all button.

Thanks!

[stevencl]

Thanks @yisibl. I understand the points you are making about the current find experience.

As you've pointed out, Sublime has a very different user experience for find and find in files. We use the small box for find and a viewlet for find in files so that we minimise the extent to which we interfere with the code that the user is browsing.

In order to accommodate richer find interactions such as the one you are proposing here we need to ensure that we minimise the amount of code we obscure when we draw the find UI. Hence my suggestion above (and the reason why we align the find UI to the right).

So without any major modifications to the current find UI, I would recommend the drop down button to expose the Find All command. That way we incorporate the new functionality without requiring major changes to the overall find UX.

[rebornix]

I'll review this PR in next iteration when I do full width find widget.

[yisibl]

@rebornix Where's the plan for "full width find widget"?

[yisibl]

I have re-updated this feature, please review.

@alexandrudima I'm not sure if the click button should call this.closeFindWidget() to close the FindWidget.I tend to close it, otherwise there will be a highlighting prompt to interfere with the user editing the text.

[alexandrogds]

@stevencl use for all (∀) symbol.

[ghost]

Best to design another codicon for it

[ghost]

I have logged a issue for adding a bespoke icon specifically for this pull and other uses of "select all" in the UI

[ghost]

It's embarrassing that this is 6 years old!

[byehack]

Find all button in other places is usually for show list of them, not select!
Btw I hope it will add by #158598 (comment)

Just an idea:
Change the color of number of founds and make it clickable.
Click on it should go to search panel with seed of current search and just include current file.
(It could have support CTRL+click to find in all files.)
Details can go under hovering.

Also, there is an extension currently do this but main problem there is no way to back previous state of search panel. (it could solve with using search editor)

[zm-cttae]

I personally think the caption should be "Select All Matches" like the exploration done in #14836.
The icon could just be expand-all or plus which is the best analog in the UI for "multi-target actions"

[zm-cttae]

@yisibl This conflicts with the new orthogonal "Find all" new window button implemented #128915 and the naming is internally inconsistent.

As some context, the #14836 issue split into two feature requests:
1. "Find all" `new-file` icon to launch a new search editor file
2. "Select all matches" `expand-all` icon

I'll try and make some suggestions ... this review should hopefully get us a working "select all" button.

[zm-cttae]

Nvm I will make a PR to your fork branch and see if I can reup this. yisibl#1

[heartacker]

hi, @rebornix , could you please take a look

[ruru-m07]

👍

[vivodi]

Is this still relevant?