emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Duration Tally


From: Eddward DeVilla
Subject: Re: [Orgmode] Duration Tally
Date: Tue, 19 Jun 2007 11:20:38 -0500

On 6/19/07, Carsten Dominik <address@hidden> wrote:

On Jun 13, 2007, at 17:33, Eddward DeVilla wrote:

>    I'm starting to wonder if it would be useful to have a general
> format for properties (or choose some other word) to be associated
> with a heading or todo item.  It seems the heading is getting a little
> crowded.
>
>    Would it be reasonable to say that a list of non-whitespace
> listing following the heading with a format of "key: value..." are
> special.  (Or a table might be nice.  I like tables.:)  org-mode could
> provide an interface to get a plist or alist of them for a heading to
> simplify writing now features based on them.

One of the advantages of using plain text for notes files like
we do with Org-mode is, that you can of course implement any system
you like to store additional information.  Keyword lists, tables,
anything.

So the discussion must be about how you would like Org-mode to make
use of such data.  Obviously it would be easy to write (as you
suggest) a little function that returns all this data as, say,
a property list.  But then you would still need to use it in
some way.  Are you suggesting tis as a feature where some users
(those who can write Lisp code) write their own extensions?
That is certainly an option.  Are you also envisioning ways
how Org-mode should use this?

Here are tow ideas:

- a LOCATION keyword would be useful for exporting to iCalendar,
   this was already proposed by Bastien a while ago.

- We could allow the TAGS match to set conditions based on these
   keywords.  Right now, a tags match can say "LEVEL=2" to require
   entries with putline level 2.  In a similar way one could allow
   "LOCATION=Paris" or whatever, that would be something quite
   easily implemented.

Nothing of this will be in todays release, obviously, this needs
more careful thinking.  Thanks for starting this discussion.

   I don't expect to see any of this soon or in this form.  It just
idea I've been trying to justify bringing up.  Where I'd want to use
it most is in custom agenda queries.  "Show me projects(todos) that
are associated with release X of product Y.  Release and Product would
be my keywords.
   Right now all we have is a TODO state and a list of tags.  Tags
are basically boolean.  You have to have a tag for each thing you want
to report on.  A tag for every product ID, a tag for every release
identifier, tags for interested parties, tags for classes, etc.  And
all the tags are mixed together in a long run-on string at the end of
the heading.  It can get unreadable.

   I also would like to be able to set a property like this that I
can then use in tables under the TODO item.  I'd have other uses for
that, but I'd like to set the property in the same way.  This isn't as
useful, but I've wished for it more than once.  Just a way to set a
variable in an org document that I can then use in formula.
Originally I thought it would be a '#' directive but I do like this as
a possible way to do it.

   While playing with these ideas and reading the message that
trigger all of this, I thought it would be nice to be able to code an
extension that would allow me to insert a keyword like TOTAL_DURATION:
that would automatically (based on some trigger) be assigned a value
equal to the sum of all the DURATION: values under the current TODO
item.  I know the original request sounded useful, but it seem very
non-general and it was yet another thing to clutter the heading.
   The property list would give us easy access to user/plugin
definable/managed fields.  I think we would want a way to hook into a
few other org-isms, like having an easy way to say C-cC-c or C-uC-cC-c
makes something happen here.  But this is all still wild fantasy of
the bizarre and possibly impractical.  I was hoping it might bring
about a better idea.

Edd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]