`Search: Find in files`: order of tab targeting

[mcrampon]

When using the Search: Find in files feature, the order in which elements are targeted by pressing TAB is counter-intuitive. It should go through the most useful items first, then go to more and more "advanced" tools.

Current behavior

Etc. For reference, before I can access the files to include text box, I have to press TAB 7 times.

Desired behavior

Etc.

[andreamah]

Please see the comment here: https://github.com/microsoft/vscode/issues/159880#issuecomment-1247538835

/duplicate https://github.com/microsoft/vscode/issues/159880

[vs-code-engineering[bot]]

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.

Happy Coding!

[mcrampon]

Please see the comment here: #159880 (comment)

/duplicate #159880

You misunderstood. I 100% agree with that comment:

users want to tab to the replace box much more often than they want to tab to those buttons

And this behaviour is correctly used in the Search: Replace in files box. However, that is NOT the current behaviour for the Search: Find in files box. See video:

https://github.com/user-attachments/assets/9fbc6e27-027e-4127-b1f7-476cb3a38388

[andreamah]

I see, this is for the search editor. It makes sense that there's an inconsistency there that needs to be fixed.

[andreamah]

Taking another look at this, the reason why it's like this is because those are not the replace fields- those are are the 'files to include' and 'files to exclude' fields, which also exist in the search view if you click the .... The search editor's behavior would be the same as the search view's behavior if the search view had no replace field.

[mcrampon]

Taking another look at this, the reason why it's like this is because those are not the replace fields- those are are the 'files to include' and 'files to exclude' fields, which also exist in the search view if you click the .... The search editor's behavior would be the same as the search view's behavior if the search view had no replace field.

Ah, never knew you could have the include/exclude fields in the replace view. Good to know.

Indeed, there's an inconsistency on a field basis then:

https://github.com/user-attachments/assets/cc7d4747-dcb3-4cd2-82e6-a37d20623b78

[andreamah]

There currently is no support for replacing in the search editor, unfortunately. See here: https://github.com/microsoft/vscode/issues/93031

[mcrampon]

There currently is no support for replacing in the search editor, unfortunately. See here: #93031

That is not what I was talking about. I was simply confirming that the order of traversal is inconsistent. My original point still stands and should also apply to the replace view.

Search view order should be:

• Search
• Include (if displayed)
• Exclude (if displayed)
• Secondary buttons

Replace view order should be:

• Search
• Replace
• Include (if displayed)
• Exclude (if displayed)
• Secondary buttons

[andreamah]

We would still want the order to be:

• search
• replace
• secondary buttons on search input
• include
• exclude

Referencing https://github.com/microsoft/vscode/issues/159880#issuecomment-1247538835, the reason why we have the replace as the second tab element is because it's more commonly used than the secondary buttons. Indeed, it's confusing, but seems to work for majority of our users.

[mcrampon]

Is it customizable through extensions then?