emacs-orgmode
[Top][All Lists]
Advanced

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

[Orgmode] Re: Finding tasks without a specific property set


From: Bernt Hansen
Subject: [Orgmode] Re: Finding tasks without a specific property set
Date: Tue, 12 Feb 2008 11:52:28 -0500
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

Carsten Dominik <address@hidden> writes:

> Hi Bernt,

Hi :)

>
> On Feb 12, 2008, at 7:01 AM, Bernt Hansen wrote:
>> One of the things I do regularly (as part of my weekly review) is find
>> NEXT tasks with no Effort property so I can use column view to add a
>> value for each task with no effort estimate.  I'm currently using a
>> custom agenda view (N) for this.
>>
>> ,----[ Tags search for NEXT tasks with no Effort property assigned ]
>> | Headlines with TAGS match: -Effort="0:10"-Effort="0:30"- 
>> Effort="1:00"-Effort="2:00"-Effort="3:00"-Effort="4:00"- 
>> Effort="5:00"-Effort="6:00"-Effort="7:00"-Effort="8:00"/NEXT
>> `----
>>
>> I haven't found a better way to do this other than to list all
>> possible
>> Effort property values in a tags search.  What I really want to
>> match is
>> any NEXT task with no Effort property (or a Effort property value that
>> is blank)
>>
>> Is there a way to do that?
>
>
> Yes there is: You can use a regular expression matching the empty
> string:
>
>  Effort={^$}/NEXT
>
> What also should work (but does not...) is
>
>  Effort=""/NEXT
>
> This will work in the next version, an I hope to document this with an
> example.
>
>> I could just do a todo search for NEXT and go to column view and scan
>> down the list for blank entries... but my list of NEXT tasks is long
>> (currently 140).  Hmmm actually that isn't too bad and the NEXT todo
>> search is much faster than my "Next Tasks - No Specified Duration"
>> search which takes 6-10 seconds to execute.
>

> That is really long.  One possible reason is that you might have
> turned on
> property inheritance.  If this is on and you check a property that
> does not
> exist locally, Org-mode has to go back all the way to the top level
> for each headline it checks.  If you have tuned inheritance on, please
> consider to restrict it to a few properties.

Property inheritance is off.  I think it's probably due to the number of
lines in my org-files that are in org-agenda-files.  These org files
(and yes I archive them... :) currently have 10522 lines totalling
551623 bytes...

>
> Since you are looking only for NEXT entries you can also speed things up
> by requiring that the entry is a TODO.  You can do this by using
> `tags-todo' instead of `todo' when defining the custom command, or by
> writing the search as (note the "!" after the "/").
>
>  Effort={^$}/!NEXT
>

Thanks! That's much faster.

> I'd be interested what happens to your timing with these improvements.

Headlines with TAGS match: 
-Effort="0:10"-Effort="0:30"-Effort="1:00"-Effort="2:00"-Effort="3:00"-Effort="4:00"-Effort="5:00"-Effort="6:00"-Effort="7:00"-Effort="8:00"/NEXT

6-7 seconds
---

Headlines with TAGS match: Effort={^$}/NEXT

6-7 seconds
---

Headlines with TAGS match: 
-Effort="0:10"-Effort="0:30"-Effort="1:00"-Effort="2:00"-Effort="3:00"-Effort="4:00"-Effort="5:00"-Effort="6:00"-Effort="7:00"-Effort="8:00"/!NEXT

1-2 seconds
---

Headlines with TAGS match: Effort={^$}/!NEXT

1-2 seconds

I'll use the last one -- Thanks!


>
> Reasonably cryptic all this, I know.  This is what happens when you
> add features with time instead of designing the full thing from the
> start.

Yes... but that's why it's so useful -- development is mostly driven by
real world problems and needs and not some theoretical "Wouldn't it be
nice to have this cool feature" requests.

>
>> Maybe I answered my own question :)
>
> and I hope I added another perspective.

Yes thanks!

-Bernt




reply via email to

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