Search while you type...

[jukzi]

I dislike to need to open search dialog again and again. I dislike to press OK.
Idea: add a search input field to the search result view (like the filter in the error log). the value entered is shared with the fine grained search dialog.

I made a short proof of concept and would like to get feedback:

[laeubi]

Some ideas where collected already here:

• Search dialog should become a search view which is not blocking #883

[mickaelistria]

The use-case demonstrated in the report is not realistic, it would be nice to get a concrete existing user-story that would really emphasize on what the proposal would resolve much better.
I think the various issues should be taken separately: "I dislike to need to open search dialog again and again" and "I dislike to press OK" are IMO distinct enough to be considered separately. I'm convinced that considering those separately will lead to better implementations.

For example, the 1st one, there is already have a "Re-run the current search" button that can cover this.

Also the suggested approach seems to mostly work for Text Search, while there are other Search types one would also want to make more efficient.

[jukzi]

For example, the 1st one, there is already have a "Re-run the current search" button that can cover this.

I want to search for "a" and then for "b"-- rerun does not help without changing the text i am trying to search. the implementation actually uses the research button - but changes the search text before doing so. Its's a pitty you rate a proposal without even trying it out. Filtering input is a very common concept from other views so to me it feels very natural and intuitive.

Also the suggested approach seems to mostly work for Text Search, while there are other Search types one would also want to make more efficient.

All other providers just need to implement this too - that's very simple:

String getSearchString();
void setSearchString(String s);

[mickaelistria]

I want to search for "a" and then for "b"

OK, and do you usually use Ctrl+F or Ctrl+H or Ctrl+Alt+Shift+L or ... to do so? Ie do you need integration with search view or is it more about incremental search? Because those are different beasts so far (although there is now "Select All" on the Ctrl+F dialog which has gotten them closer functionally for single files).
Would the search via the proposed filter restrict to a single scope, or would it work with other search types?
I'm afraid if we make the Search field too prominent, then we may get people failing at discovering the Search dialog which allows more powerful search. You may not like clicking OK, but sometimes, a well defined search and clicking OK would lead people to get their results more efficiently than by going for something incremental just because it's more accessible.
Hence why I'd like to get more details about the particular user-stories this is aimed to serve.

[jukzi]

OK, and do you usually use Ctrl+F or Ctrl+H or Ctrl+Alt+Shift+L or ... to do so?

I am a mouse user. I am used to click through the menus. Typically i copy a text, open search and paste it (or it is already selected) crtl+v +OK. With the proposed solution i could just paste it in the search field.
The other search providers do not have key short cuts anyway:

Would the search via the proposed filter restrict to a single scope, or would it work with other search types?

Try it out! It works with all the fancy options, just not showing them.

people failing at discovering the Search dialog

No way: They will try to press ENTER key at some time for sure.
Maybe it's not perfect or you find a better solution, but please try it before complaining?

The user story is simply that i am used to search while type due to firefox/chrome - and there i find the feature very useful.

[mickaelistria]

The other search providers do not have key short cuts anyway:

Ctrl+H does open the latest search provider used. File search is not different from Git search or Java search. It's just usually the 1st one in the CTabFolder so the one that's 1st visible.

I'll try the proposal, but I still think that several not-so-technically-related problems are attempted to be solved at once: improve search workflow without a mouse (eg a button to open the search dialog and/or adding a search field to start a test search on current file from the view), and making some search incremental. I would rather see those issues covered in separate patches, to facilitate reviews and make faster progress, so if you can reorganize eclipse-platform/eclipse.platform.text#81 in 2 separate PRs, it would be helpful.
Ultimately, if we can reach a state of quality that would allow to get rid of Ctrl+F in most cases, that would be a huge win. I want to make clear I support the overall idea, it's just that I prefer bringing all the questions I have right now to ensure we can make this proposal fit also in the bigger picture of basically simplifying UI and code.

[jukzi]

The other search providers do not have key short cuts anyway:

Ctrl+H does open the latest search provider used.

may be in theory. in practice for java it is:

making some search incremental.

hah, that would be cool. technically it's just a complete restart by now. only lot of bloat code to solve MT issues that have not been found yet, since it was not usual to start multiple searches in quick succession. that could be separated but i will avoid any further work until we have a common goal.

Ctrl+F

in-document-search is not part of this change either! would be cool too. but yet totally unrelated to search providers / search result view
There are so many features that could be added ... later.