* org-entry-get bugs etc.
@ 2010-01-13 23:09 Samuel Wales
2010-01-14 18:42 ` Carsten Dominik
0 siblings, 1 reply; 2+ messages in thread
From: Samuel Wales @ 2010-01-13 23:09 UTC (permalink / raw)
To: emacs-orgmode
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.
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.
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.
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.
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.
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.
Thanks.
Samuel
--
Q: How many CDC "scientists" does it take to change a lightbulb?
A: You only think it's dark. [CDC has denied ME/CFS for 25 years]
=================================================================
Retrovirus: http://www.wpinstitute.org/xmrv/xmrv_qa.html
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: org-entry-get bugs etc.
2010-01-13 23:09 org-entry-get bugs etc Samuel Wales
@ 2010-01-14 18:42 ` Carsten Dominik
0 siblings, 0 replies; 2+ messages in thread
From: Carsten Dominik @ 2010-01-14 18:42 UTC (permalink / raw)
To: Samuel Wales; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-01-14 18:48 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-13 23:09 org-entry-get bugs etc Samuel Wales
2010-01-14 18:42 ` Carsten Dominik
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).