-
Notifications
You must be signed in to change notification settings - Fork 121
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
Document the new "OR" operator #584
Conversation
|
||
.. note:: | ||
The spelled-out "OR" operator is case-sensitive, i.e. searching for ``or`` will search for the literal string ``or``. Using the quoted form ``"OR"`` will also search literally. | ||
|
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 feel that, in this place, this important section does not get the attention it deserves.
What do you think about moving it up, below the first paragraph?
Using search operators
Search operators allow you to form more complex search queries. They allow you to limit certain search terms to particular properties of your tracks.
<--
Mixxx supports the following filters:
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.
The failing link check is unrelated (we need to merge 2.3 into 2.4, 2.4 into main) and pre-commit only found a trailing whitespace.
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.
My idea was to first introduce the "OR" operator itself, then the spelling and finally discuss this rather unusual (but not inconceivable) edge case/gotcha where the user might unintentionally use the "OR" operator. Note that this only happens when the word "OR" is delimited by boundaries/whitespace. In other words, words that only contain "OR" as a substring are unaffected, so I would expect such queries to be pretty uncommon in practice. Users searching in lowercase would never run into this anyway.
Also I think it would be nice to keep everything about the "OR" operator in a single section.
Could you elaborate on why this note deserves more attention?
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.
Also I think it would be nice to keep everything about the "OR" operator in a single section.
Of course. I think this was just a misunderstanding, by 'section' I mean the entire new OR section.
Anyway, the placement is fine for now, maybe it's just that I find the current stylesheet a bit inconclusive, so it's a general issue IMHO. With the bullet points it looks like OR belongs Special filtering.
Maybe it would help if OR gets a headline Combine filter with OR.
Later on we may move some AND examples from Special filtering to Combine filters where we clarify the default AND and explicit OR. But that's out of scope here.
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.
Ah sorry, yeah, that was a misunderstanding on my part. That sounds good!
Thank you very much for this PR (and the OR PR itself!). Please remove that, then squash all commits and force-push? |
Thank you! |
As a sibling PR to mixxxdj/mixxx#12061, this documents the new "OR" operator.
https://deploy-preview-584--mixxx-manual.netlify.app/chapters/library#finding-tracks-search