Case-folding for `property` predicate?
If I do org-ql-sparse-tree and search for property:tested y I get the same result as if I search for property:tested Y .
If I use org-ql-search instead I get different results searching for (property "TESTED" "Y") and (property "TESTED" "y").
case-fold-search is set to t. Am I doing something wrong?
Hello Bob,
Well, there appear to be a few different issues at play here.
- When you call
org-ql-sparse-tree, you're using non-sexp queries, equivalent to(and (property "TESTED") "y")and(and (property "TESTED") "Y"). (If you want theyto be passed to theproperty:predicate, you must use a comma between arguments, i.e.property:tested,y). - When you call
org-ql-searchyou're using sexp queries(property "TESTED" "Y")and(property "TESTED" "y"), which are not the same queries as in 1. - Finally, Org itself case-folds at least some aspects of properties. For example, if you use
(org-entry-get nil "PROPERTY-NAME"), you'll see that it will return a value for bothPROPERTY-NAMEandproperty-name.
As expected, user error is at play. So to search for upper case property names and values should I be doing one of:
non-sexp property:TESTED,Y
sexp (property "TESTED" "Y")
?
Ideally I'd like to be able to search for a property name and value where the case is ignored for both. In either above example case is respected for name and value.
@AndrewGabelliTR Those sexp and string queries are equivalent. If a case were found in which they were not 1:1 compatible, it would be a bug.
If you want to ignore case (i.e. enable case-folding in Emacs jargon), you'll need to define your own property matcher that either case-folds by default or adds a keyword argument to do so: https://github.com/alphapapa/org-ql/blob/3dc2409539eb67206954effdcb22f1a78f52ab56/org-ql.el#L1802 By default, the code compares values with string-equal, so it is case-sensitive. (And, as noted, Org compares property names case-insensitively.)
A keyword argument for this could be added if needed, or one to use a regexp to match against properties and/or values, but I don't know if it would be widely used enough to be worthwhile. Maybe you could share a bit more about your use cases?
What do you think? Thanks.
If you want to ignore case (i.e. enable case-folding in Emacs jargon), you'll need to define your own
propertymatcher that either case-folds by default or adds a keyword argument to do so:
That's a bit above my emacs pay grade unfortunately.
A keyword argument for this could be added if needed, or one to use a regexp to match against properties and/or values, but I don't know if it would be widely used enough to be worthwhile. Maybe you could share a bit more about your use cases?
Sure. I want to treat my property names and their values as case insensitive as far as possible, including being able to carry out case insensitive searches. I typically have a two-level property structure consisting of Module and Submodule. However I'm not disciplined enough to use e.g. MODULE all the time and might use Module, or even module if I'm feeling really lazy. I want any combination of case to refer to the same property, and I want this case insensitivity to be reflected when I search.
I seem to be able to get a sparse tree or agenda view by using regexes in my search e.g. module={foo}+submodule={bar} and I thought it'd be nice if org-ql-search was able to do the same thing. Apologies if I'm asking for something off-piste.
If you want to ignore case (i.e. enable case-folding in Emacs jargon), you'll need to define your own
propertymatcher that either case-folds by default or adds a keyword argument to do so:That's a bit above my emacs pay grade unfortunately.
I wouldn't jump to that conclusion. See the tutorial, for example: https://github.com/alphapapa/org-ql/blob/master/examples/defpred.org
A keyword argument for this could be added if needed, or one to use a regexp to match against properties and/or values, but I don't know if it would be widely used enough to be worthwhile. Maybe you could share a bit more about your use cases?
Sure. I want to treat my property names and their values as case insensitive as far as possible, including being able to carry out case insensitive searches. I typically have a two-level property structure consisting of Module and Submodule. However I'm not disciplined enough to use e.g. MODULE all the time and might use Module, or even module if I'm feeling really lazy. I want any combination of case to refer to the same property, and I want this case insensitivity to be reflected when I search.
Another option would be to run a simple function that sets all of those properties to have the same capitalization in your files.
I seem to be able to get a sparse tree or agenda view by using regexes in my search e.g.
module={foo}+submodule={bar}and I thought it'd be nice if org-ql-search was able to do the same thing. Apologies if I'm asking for something off-piste.
Maybe that part of Org does case-folding, but internally the different capitalization produces different keyword symbols in the parsed elements.
There's nothing wrong with what you're asking for; it's just a matter of taking the time to implement it. If you copied the existing predicate definition and changed the comparison to be case-folding, that would be like a one- or two-word change.
OK I found the function org-ql-defpred property in .emacs.d.spacemacs/elpa/develop/org-ql-20230908.722/org-ql.el and changed the string-equal call at the end to string-equal-ignore-case. I restarted emacs but the behaviour didn't seem to change. I also created a copy of the entire function in my config file and edited that, same result.
I'm really not a lisper as is probably super clear. How to I get the change to stick please? Assuming I've done the right thing of course...
This is reaching the limit of how much help I can provide in this issue, because it's moving into general Emacs territory; as well, since you're using Spacemacs, that sometimes causes its own issues, especially because of its bespoke configuration system.
Anyway, you generally shouldn't modify the code in installed packages' files, because that code is byte-compiled, which is often loaded in preference to uncompiled files, and it means that you no longer have the original source code to load.
The idea here, given the defpred macro and tutorial, is to define your own version of the predicate that works as you desire (i.e. with a different name, so the original predicate's behavior is preserved). That should be put in your configuration to be loaded when org-ql is.
Fair enough. Thanks for your comments.
Fair enough. Thanks for your comments.
You're welcome. If you need more help, feel free to open a "discussion" (rather than an issue). You could also discuss it on Reddit, e.g. on r/orgmode.
Other than that, I'll leave this issue open, because I'm not sure if org-ql needs to do some kind of case-folding for properties or their values by default to match Org's behavior.