Bug 224141 - Find in files should not require wildcards in File Name Patterns
Find in files should not require wildcards in File Name Patterns
Status: RESOLVED FIXED
Product: utilities
Classification: Unclassified
Component: Search
7.3
PC Mac OS X
: P3 (vote)
: 7.4
Assigned To: Jaroslav Havlin
issues@utilities
: UI, UI_REVIEW
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-21 16:49 UTC by Petr Jiricka
Modified: 2013-02-19 01:50 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
:


Attachments
Patch for testing new behavior (2.53 KB, patch)
2013-01-07 10:17 UTC, Jaroslav Havlin
Details | Diff
Proposed Patch - Back-end wildcards (101 bytes, patch)
2013-01-16 15:11 UTC, Jaroslav Havlin
Details | Diff
Proposed Patch - Back-end wildcards (4.34 KB, patch)
2013-01-16 15:49 UTC, Jaroslav Havlin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Jiricka 2012-12-21 16:49:35 UTC
1. Open a project with existing files, which contains e.g. Main.java
2. Open Find in Projects dialog
3. Type "Main" in the File Name Patterns field and confirm the dialog

=> Nothing will be found. For Main.java to be found, I would have needed to specify "Main*". I would expect that while wildcards should be accepted as they are now, for simple substring search on file names, wildcards should not be required and it should be enough to type "Main" to find Main.java.
Comment 1 Jaroslav Havlin 2013-01-03 14:43:45 UTC
> I would expect that while wildcards should be accepted as they
> are now, for simple substring search on file names, wildcards should not be
> required and it should be enough to type "Main" to find Main.java.
Good idea. We should discuss the corner cases.

Text Main could be automatically transformed to one of:

1. Main*
2. Main.*
3. *Main*

(other variant are probably not very useful).

Which one would you prefer?

But what if someone needs to find files with name "Makefile" and doesn't want to include "Makefile.in", "MakefileTest", or "SomeMakeFile"? They need to use regular expression "/Makefile$", which is it not very intuitive.
Is it a problem?

What do you think?
Thank you.
Comment 2 Petr Jiricka 2013-01-03 15:25:45 UTC
Option 3 is my preference.

You are right about the need to use regular expressions in some cases, I don't have a strong opinion whether this is a big problem or not.

Another possibility I just thought of is: when the user starts typing, automatically prepend and append * to his text, so the user can clearly see that the field expects wildcard syntax, and can delete the wildcard if needed. So after I type abc, the field would display *abc*.
Comment 3 Jaroslav Havlin 2013-01-07 10:17:54 UTC
Created attachment 129953 [details]
Patch for testing new behavior
Comment 4 Jaroslav Havlin 2013-01-07 10:43:57 UTC
> So after I type abc, the field would display *abc*.
Nice solution.

I think that the wildcards (stars) should be added to the text after the first letter is typed (so the stars are close to the cursor if the user wants to remove them).
If the first letter is not a word character, wildcards should not be added.
After the wildcards are deleted, they should not be automatically added again.

Adding uireviews to CC list. Please, do you have any opinion?

It is probably too late to integrate it into 7.3 after the UI freeze.
Comment 5 Stanislav Aubrecht 2013-01-07 11:07:46 UTC
The field name says 'File Name Patterns" so I guess it clearly indicates a *pattern* with wildcard chars is expected.
Perhaps the combo box could include a few examples by default, e.g. *.txt, *.java
Comment 6 Petr Jiricka 2013-01-07 12:10:23 UTC
That could help a bit, but I don't usually expand the combo box, so I still don't think it's ideal. Besides, discoverability is just a part of the problem, the other thing is that I need to type the extra one or two * characters, when the IDE could save these keystrokes for me (I believe most of the time people search for substrings).
Comment 7 richgunther 2013-01-07 17:38:03 UTC
All,
This is one of those things that, whatever we do here, we want to do everywhere throughout the UI.  I believe other filter and search controls imply the wildcard characters...they don't put them into the textbox, they just add a wildcard to the beginning and end of the search term on the backend when building the query.

Rich
Comment 8 Stanislav Aubrecht 2013-01-08 09:00:27 UTC
I think that File Name Pattern field is different from search fields in other parts in NetBeans. I often enter patterns like *.properties or *.xml when searching for something.
So how about setting the default field content to "*|*" when it is focused? The | char indicates cursor position.
Comment 9 Jaroslav Havlin 2013-01-08 13:52:20 UTC
(In reply to comment #8)
> So how about setting the default field content to "*|*" when it is focused? The
> | char indicates cursor position.
It would also help, but if you want to put e.g. "*.c", you have to delete one of the stars, which could be uncomfortable for users that are used to the current (trivial) implementation.
We could also delete the two auto-inserted stars if the first typed character is a star, too. But it seems quite over-complicated to me.

(In reply to comment #5)
> The field name says 'File Name Patterns" so I guess it clearly indicates a
> *pattern* with wildcard chars is expected.
I agree. The question is whether we want to help users write the patterns, or just explain what type of input is expected. I think the latter would be also sufficient.
> Perhaps the combo box could include a few examples by default, e.g. *.txt,
> *.java
If this solution is chosen, we could also display a hint saying e.g. "Didn't you forget to use wildcard characters?" if a simple string is entered into the field.
Comment 10 richgunther 2013-01-08 15:08:11 UTC
I agree: it all seems over-complicated to have the asterisks auto-populated, or some other logic in the field when you type an asterisk, etc.

My question is WHY is it required that they enter a wildcard character?  Can't we assume that they always want to do a *(search term here)* style search and not require the wildcards?
Comment 11 Jaroslav Havlin 2013-01-09 09:53:07 UTC
(In reply to comment #10)
> My question is WHY is it required that they enter a wildcard character?  Can't
> we assume that they always want to do a *(search term here)* style search and
> not require the wildcards?
I think there are some reasons (that should be discussed):
 1) It would be difficult to search for exact file name (see comment #1).
   - Similar problem is in bug 224328, please consider CCing uireviews there.
 2) Pattern is expected (standard for Unix and Windows, comment#5).
 3) It should be obvious what's going to happen (what pattern will be used).

We could change the label to e.g. "File Name" and explain semantics of the field in tooltip and in help, but reason 1) would be still valid.
I just can't estimate whether 1) would be a problem for some users or not.

I think the safest and still sufficient solution is this:
> > Perhaps the combo box could include a few examples by default, e.g. *.txt.
> We could also display a hint saying e.g. "Didn't you forget to use wildcard 
> characters?" if a simple string is entered into the field.
Comment 12 richgunther 2013-01-14 15:31:04 UTC
Hi, circling back around on this issue.  I don't think I was clear the first time.  I am not proposing that we abandon a wildcard search and replace it with a simple string search.  I'm proposing that we allow the user to enter a search term without the wildcard modifier, and then on the back-end, when we run the query, insert wildcards on either end for them (not in the UI, just in the query itself).  This would, I believe, make it consistent with other search/filter fields in the IDE.

Rich
Comment 13 Jaroslav Havlin 2013-01-16 10:16:40 UTC
(In reply to comment #12)
> I don't think I was clear the first time.
You were. I wasn't, sorry.

> I'm proposing that we allow the user to enter a search term without the
> wildcard modifier, and then on the back-end, when we run the query, 
> insert wildcards on either end for them 
There could be one corner-case problem.

Example:
I have a project that contains many files (in different directories) with these names: "Makefile", "Makefile.bac", "TestMakefile".
I want to search ONLY in files with (exact) name "Makefile".
So I open Find in Project dialog and enter value "Makefile" to field "File Name Patterns:". Then I run the search.
In the search results, I see files with name "Makefile", but also files with name "Makefile.bac" and "TestMakeFile", because the wildcards were added in the back-end. This is something that I didn't expect. So it probably breaks the principle of least surprise.
If I want to search for exact name, I have to use Regular Expression mode, which is not very intuitive, but possible.

The question is whether it's OK to break the least surprise principle in this (minor) case. What do you think?

Probably we can use the "wildcards in back-end" solution and reopen the issue if there are any complaints.
Comment 14 Jaroslav Havlin 2013-01-16 15:11:43 UTC
Created attachment 130290 [details]
Proposed Patch - Back-end wildcards
Comment 15 Jaroslav Havlin 2013-01-16 15:49:22 UTC
Created attachment 130291 [details]
Proposed Patch - Back-end wildcards

Attaching correct file.
Comment 16 richgunther 2013-01-16 18:55:34 UTC
Could we architect this using a UNION query with string-literal query in the first query and wildcard characters in the second?  That would return exact matches first and then "close" matches afterwards, which I think would overcome the issue you describe.

Rich
Comment 17 Antonin Nebuzelsky 2013-01-18 13:58:24 UTC
IMO adding wildcards automatically would be confusing. The meaning of the word Pattern in the name of this field should be obvious to all users and they would be surprised to see more results than they expected, regardless of ordering of the results.

Including some pattern examples in the combo dropdown as suggested above would be the best way to go IMO.
Comment 18 Petr Somol 2013-01-18 16:33:24 UTC
(In reply to comment #17)
> IMO adding wildcards automatically would be confusing. The meaning of the word
> Pattern in the name of this field should be obvious to all users and they would
> be surprised to see more results than they expected, regardless of ordering of
> the results.
> 
> Including some pattern examples in the combo dropdown as suggested above would
> be the best way to go IMO.

I did not join this discussion before as it seemed difficult to come up with a good solution. Just commenting now that the proposal in Comment #17 sounds good to me, in order to prevent possible confusion with users.
Comment 19 Jaroslav Havlin 2013-02-18 16:03:02 UTC
(In reply to comment #18)
> I did not join this discussion before as it seemed difficult to come up with a
> good solution. Just commenting now that the proposal in Comment #17 sounds good
> to me, in order to prevent possible confusion with users.
OK, implemented in http://hg.netbeans.org/core-main/rev/4ec39a1a8d98

By the way, no wildcards are required if option "File Path Regular Expression" is checked, which could satisfy most users who dislike wildcards.

Thank you for your comments.
Comment 20 Quality Engineering 2013-02-19 01:50:28 UTC
Integrated into 'main-golden', will be available in build *201302182300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/4ec39a1a8d98
User: Jaroslav Havlin <jhavlin@netbeans.org>
Log: #224141: File name patterns, missing wildcards, default patterns


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo