-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Switch colors of search icon for the two search modes #3871
Conversation
Grammar-based search is the advanced search. So, the magnifier should be cyan, when following search string is active:
Taking examples from the documentation (https://help.jabref.org/en/Search#search-modes) All of these are advanced, but they are not recognized as such:
Following is normal mode:
This is now with cyan. This is wrong. Following is normal mode:
Correctly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fix is not in line with the intention of basic and advanced mode. basic is non-grammar-based, advanced is grammar-based
If so, the whole detection is wrong?! |
Only the beginning of the detection is somehow wrong. For complex terms it is right, but for single words, it is wrong. See the examples above. Maybe, we changed something when going from JabRef 3.6 to 3.7. |
Or maybe the detection never was entirely correct. If I have a lot of time on my hands, I might have a look at the detection algorithm. Otherwise we can close this PR and / or remove the coloring of the the search icon again. After all, what is the point of changing its color if the circumstances are incorrect? |
It worked in 3.6 and no one noticed that it broke at 3.7. So, the point is
to keep the idea and to fix it... The idea in other words: make users aware
of the feature and that the search might not work if the grammar based
search was intended, but not matched (typo in query)
Am 22.03.2018 19:53 schrieb "Jörg Lenhard" <notifications@github.com>:
Or maybe the detection never was entirely correct. If I have a lot of time
on my hands, I might have a look at the detection algorithm. Otherwise we
can close this PR and / or remove the coloring of the the search icon
again. After all, what is the point of changing its color if the
circumstances are incorrect?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3871 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABTafiYxOvx2TOF6vCt2ytpyzzRUWwEvks5tg_McgaJpZM4S1MHL>
.
|
Actually there should be tests for it then, as this is not a UI feature but the detection is logic based... |
Did we update the antlr stuff after v3.6? Because the query "progress" actually is a valid grammar-based query that compiles with our antlr code. That's the reason for the "wrong" coloring. I have now added code that checks if a query consists only of word / whitespace characters and/or digits and uses a normal contains-based query for that. Thus, grammar-based searches are only executed when special symbols are used ALTHOUGH our grammar is more powerfull than that. The terms mentioned by @koppor above are now colored as expected. @koppor: I hope this limitation is what is wanted. Please do some testing to see if this matches your expectations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments. In general, it resolves the issue!
@@ -85,7 +85,7 @@ private String getLocalizedRegularExpressionDescription() { | |||
} | |||
|
|||
public boolean isGrammarBasedSearch() { | |||
return rule instanceof GrammarBasedSearchRule; | |||
return rule instanceof GrammarBasedSearchRule || rule instanceof RegexBasedSearchRule; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should regex really be treated as grammar-based search? I would not treat it like that, because regex search is orthogonal to grammar-based search. One can activate it in addition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least in the documentation: https://help.jabref.org/en/Search#search-modes they are listed under the heading of "advanced search". But I can easily change that of course.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the help accordingly to also reflect that regular expressions are orthogonal. 😇
Could you additionally add a comment there that this is the "Advanced Search" described in the help? I know, this contradicts DDD, but I think, it is OK in this place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I adapted the code accordingly.
/** | ||
* Returns the appropriate search rule that fits best to the given parameter. | ||
*/ | ||
public static SearchRule getSearchRuleByQuery(String query, boolean caseSensitive, boolean regex) { | ||
if (StringUtil.isBlank(query)) { | ||
if (isSimpleQuery(query)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reads good!
@@ -25,6 +29,10 @@ public static SearchRule getSearchRuleByQuery(String query, boolean caseSensitiv | |||
} | |||
} | |||
|
|||
private static boolean isSimpleQuery(String query) { | |||
return StringUtil.isBlank(query) || simpleExpression.matcher(query).matches(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you really need both? The current regex has a star (*
) at the end, which means zero (0
) ore more matches. So, the empty string should match, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good suggestion, that sounds reasonable. I removed the StringUtil dependency and as far as I can see there is no difference in the search.
Thanks for the comments @koppor I fixed all the glitches you described and this PR should now be ready. |
* upstream/master: Pdf exporter - delete xmp actions in the menu bar and the cli option (#3947) Improve search performance (#3950) New Crowdin translations (#3949) Update dependencies for junit, mockito and checkstyle (#3951) Add XMP Exporter (#3895) Switch colors of search icon for the two search modes (#3871) # Conflicts: # src/main/java/org/jabref/gui/search/GlobalSearchBar.java
Fixes #3870