From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: org-entry-get bugs etc. Date: Thu, 14 Jan 2010 19:42:54 +0100 Message-ID: <3217B2FC-9D92-4645-A28A-E0B613B96881@gmail.com> References: <20524da71001131509r72741172k95c54abf80776b32@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NVUkI-0004Gh-3a for emacs-orgmode@gnu.org; Thu, 14 Jan 2010 13:48:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NVUkD-00048L-AE for emacs-orgmode@gnu.org; Thu, 14 Jan 2010 13:48:37 -0500 Received: from [199.232.76.173] (port=38003 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NVUkD-00047t-3m for emacs-orgmode@gnu.org; Thu, 14 Jan 2010 13:48:33 -0500 Received: from mail-ew0-f209.google.com ([209.85.219.209]:41107) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NVUkC-0006Wt-Hx for emacs-orgmode@gnu.org; Thu, 14 Jan 2010 13:48:32 -0500 Received: by ewy1 with SMTP id 1so36977ewy.8 for ; Thu, 14 Jan 2010 10:48:28 -0800 (PST) In-Reply-To: <20524da71001131509r72741172k95c54abf80776b32@mail.gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Samuel Wales Cc: emacs-orgmode@gnu.org On Jan 14, 2010, at 12:09 AM, Samuel Wales wrote: > I ran into a bug in which org-entry-get returns the wrong > value. It brought up some other points. > > 1) org-entry-get of "TODO" returns the wrong value when > there is a lower case version of a todo kw on a > headline. Example: > > * neowhen > > I have "NEOWHEN" as a todo kw. > > What it returns is "neowhen". What I think it should > return is the value for a blank state. Currently, this > value is nil. Thanks for you patient work to find these places. I have fixed this one as well, just like you earlier discoveries. > 2) This is the 5th bug that I have reported of this type. > In all 5 cases, the lower case version of a todo kw at > the beginning of a headline caused incorrect behavior. > This suggests separate matches. At least as a > possibility. Yes, these are all individual matches, unfortunately. > > This in turn suggests to me that it might be possible > to refactor org. By this I mean create a wrapper to do > the matching and call that wrapper in all of those > places. I wish I could help here, but I cannot. This is possible, but a huge amount of work which might introduce more bugs. I think we really have caught most of these now, thanks to you. > > 3) For the user, I think it is more convenient to use > org-entry-get for metadata than to parse manually. > This is a useful function. Yes, it is, and now it also is reasonably fast. It used to be ridiculously slow for all the meta-data properties. But now this is acceptable, thanks to a recent change. > > 4) Perhaps Lisp keywords can be allowed instead of strings > for speed. For example, > > (org-entry-get point-or-marker :todo) > > Instead of: > > (org-entry-get point-or-marker "TODO") > > I don't know if it would be significant. I don't think it makes a measurable difference for speed. > > 5) This isn't directly related, but the value for a blank > state is currently nil, not "". I have not thought > about this deeply, but as nil is not a string, it is a > special case (i.e. the only state that is not a > string). In my experience, special cases in return > values cause complicated code, because calling code > needs to special-case the special case instead of > merely composing, funcalling, or applying. Perhaps > it's too late to change that. Or perhaps there is a > special reason to use nil. But seems worth mentioning > just in case it triggers an idea. This goes both ways! I often have to check if there is a todo keyword, so for me the nil value is convenient. Otherwise I would have to test (and todo (not (equal todo ""))) For the normal properties, the difference between nil and "" is actually significant. nil means the keyword is not there, "" means it is there but the value is empty. Thanks, as always, for your thoughtful contributions. - Carsten