emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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.

   Ex: (org-make-tags-matcher "P<<2") produces

    ("P<<2" and
     (progn
       (setq org-cached-props nil)
       (nil
        (string-to-number (or (org-cached-entry-get nil "P") "")) 2))
     t)

3. A faulty test for todo matcher in org-make-tags-matcher

   The current code uses (string-match "/+" match)
   to detect the presence of the shortcut /!? style todo matchers.
   But this is insufficient.

   Ex: (org-make-tags-matcher "PROP={^\\s-*// .*$}") produces
   an erroneous matcher:

       ("PROP={^\\s-*// .*$}" progn
        (setq org-cached-props nil)
        (member "PROP" tags-list))

   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.]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]