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
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
