Re: [Orgmode] org-entry-get bugs etc.

[Carsten Dominik]

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