emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Samuel Wales <samologist@gmail.com>
To: emacs-orgmode@gnu.org
Subject: org-entry-get bugs etc.
Date: Wed, 13 Jan 2010 16:09:16 -0700	[thread overview]
Message-ID: <20524da71001131509r72741172k95c54abf80776b32@mail.gmail.com> (raw)

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

next             reply	other threads:[~2010-01-13 23:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-13 23:09 Samuel Wales [this message]
2010-01-14 18:42 ` org-entry-get bugs etc Carsten Dominik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20524da71001131509r72741172k95c54abf80776b32@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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