[O] new tag query parser [2/5] -- some bugs/limitations in the current p
From:
Christopher Genovese
Subject:
[O] new tag query parser [2/5] -- some bugs/limitations in the current parser
Date:
Wed, 15 Aug 2012 23:59:11 -0400
1. Property names with -'s are not handled properly Specifically, the escapes are not removed. Ex: (org-make-tags-matcher "PROP\\-WITH\\-HYPHENS=2") produces ("PROP\\-WITH\\-HYPHENS=2" and (progn (setq org-cached-props nil) (= (string-to-number (or (org-cached-entry-get nil "PROP\\-WITH\\-HYPHENS") "")) 2)) t)
The property name in the matcher should be "PROP-WITH-HYPHENS". The original code /does/ instead remove -'s from tag names, which shouldn't have them anyway. I suspect that this was intended for property names rather than tag names. 2. Incorrect comparison operators allowed, produce bad matchers.
The regular _expression_ "[<=>]\\{1,2\\}" is used to detect the comparison operators. But this can produce bad matchers that fail opaquely at match time rather than giving an appropriate error message at parse time.
We want to find the first slash that is not enclosed in {}'s or ""'s; if found, a todo match is needed. A simple pattern will not be enough for this. As a side note, org allows arbitrary characters in TODO keywords, (For instance, both PROP={/!} and PROP="/!{/!}" are valid TODO keywords (it works!) *and* valid property comparisons.) The assumption of the current version is that {}'s and "'s are excluded. I also exclude ()'s from TODO keywords in the new version for reasons we can discuss later. Neither seems like a big loss. If you are using {}'s, "'s, or ()'s in your TODO keywords, use a TODO= match rather than a /!? match.
4. Regexp matchers in todo queries fail when no TODO for an item. Ex: (org-make-tags-matcher "/{\\S-}") produces ("/{\\S-}" and t (string-match "\\S-" todo)) This will raise an error when todo is nil (no todo keyword on a scanned item) when doing an org-map-entries, say. The todo should be replaced with a (or todo "") as it is for tag-style TODO queries.
5. A minor consistency issue At line 7179 in org.el (v 7.8.11), missing an org-re call in a regex that uses posix classes. The org-re is used elsewhere, for xemacs compatibility, I think.
[FWIW, all of these are problems eliminated or made moot in the new parser.]
[Prev in Thread]
Current Thread
[Next in Thread]
[O] new tag query parser [2/5] -- some bugs/limitations in the current parser,
Christopher Genovese<=