-
-
Notifications
You must be signed in to change notification settings - Fork 237
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
Allow parenthesis to be used in search strings in boolean filters #1308
Comments
Hi @tilmanbergt, The only thing I can suggest right now is to experiment with double quotes around your search expressions. In the documentation of boolean queries - https://obsidian-tasks-group.github.io/obsidian-tasks/queries/combining-filters/#syntax - I recommended against using them as equivalents to parentheses. I don't remember what happened in testing, exactly, that prompted me to say that. However, you might find, for example, that if you had a search string that had () and no double quotes, that surrounding the filter with " may work. Please could you report back on what you find. Ohhh... the other thing you could try is to use a regular expression search. |
A code-based option is to make the Boolean filter parsing less greedy, so that it ignores parens that are not next to one of the Boolean operators AND OR etc. That might solve this problem without needing to add the ability to escape characters in filters. |
Hi @claremacrae, thanks so much for responding to this. I already experimented a little with quotes it seems to make things rather worse, causing every query to say: Tasks query: do not understand query: "description includes #next work on my demons on this" Have now the following approach which works (but is of course a workaround):
|
Thanks for the reply. For future reference, any information on what you have already considered or tried is always very helpful in feature requests and bug reports, both to add context, and to save spending time writing up things that are already known or already tried. I doubt very much indeed that using a regular expression would make a perceptible difference to the search speed, so I would encourage you to try that. just exploring an actual fix, the description of this feature request is currently to allow escape characters in description searches, which is quite a general thing. But I wonder, would actually the ability to use ( or ) in Boolean filters in text searches be sufficient? Am asking as I think it is more specific and maybe likely more doable. |
In the meantime, another workaround is to split descriptions on ( and ) and have use AND to combine the components…. (a AND b AND C) OR d or E |
yes, sorry for not including that in my initial description. and also thank you for the second work around idea. I will see if this can be done, looks like a promising approach. Also I might look into the regular expressions, but somehow have worked not enough with them recently to have a good feeling of side effects. And to your question: yes: I will rename the title into allowing parenthesis in boolean filters. |
Hi @tilmanbergt In case it helps you convert your search to using regular expressions... Need to escape ( and other characters with special meaningThe issue with taking any arbitrary search text and searching for it using regular expressions is that various ASCII characters that might be present in the search string have special meanings in regular expressions, and so need to be "escaped", to remove their special meaning. The Tasks docs on regular expressions cover escaping of special characters. Code from Tasks you could copyHowever, there is some code in Tasks that you are welcome to crib, that does this escaping for you, for a given string. The commit in Tasks that tested and proved (sufficiently) correct a function to do this escaping is as follows - mainly to show you the extent of testing I did to satisfy myself that the code behaved correctly: You can see I would suggest copying it as this, to credit the version you copied: /**
* Escape a string so it can be used as part of a RegExp literally.
* Taken from:
* https://github.com/obsidian-tasks-group/obsidian-tasks/blob/04c621db3117b8ccaaa57c10ea212c682e27e716/src/Task.ts#L878:L897
* MIT licence
*/
private escapeRegExp(s: string) {
return s.replace(/([.*+?^${}()|[\]/\\])/g, '\\$1');
} Suggested routeSo your steps would be something like:
I'm on mobile at the moment so not able to try it out. I do appreciate this is all a sticking plaster for now, but I hope it will get you going. Sharing the resultsIf you could share what works, I'll look at including it in the Tasks docs, to help others out.... |
(Example code in previous comment updated to include the licence of copied code) |
This will be fixed by the solving of |
Managed to work around a similar issue I had with file paths having parentheses based on the suggestion above: function escapeRegExp(s) {
return s
.replace(/([.*+?^${}|[\]/\\])/g, "\\$1")
// replace parens w/ hex escapes
.replaceAll("(", "\\x28")
.replaceAll(")", "\\x29");
} |
Hi @akatopo - thank you. Where did you use that code please? |
🔖 Feature description
Use Case: I create tasks queries programmatically via dataviewjs using the following script:
This works pretty fine to return some fragment I can then insert via dv.paragraph anywhere to get fully functioning tasks based on a array of tasks. The only situations in which it currently fails is when the task description contains brackets ("(", ")"), because they interfere with the syntax for creating "OR" queries in tasks.
I did not find any mention of escaping them by any means. Are there any? Otherwise I would propose to allow some escaping.
Please let me know any other approach to this scenario that could help.
Thank you so much for considering this request.
✔️ Solution
e.g. ignore brackets that are prefixed with "" allowing something like .replace("(","\(") to be used.
❓ Alternatives
Another approach would be to allow lines to start with "OR", but this would probably insert too much ambiguity.
📝 Additional Context
As background: I have quite elaborate rules for displaying certain tasks that can not easily be covered by the tasks syntax itself (particularly making sure tasks already shown in some section are not again shown in a different section).
The text was updated successfully, but these errors were encountered: