[Top][All Lists]

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

Re: [Orgmode] Re: skip entry with inherited tags

From: Martin Pohlack
Subject: Re: [Orgmode] Re: skip entry with inherited tags
Date: Wed, 04 Aug 2010 23:38:07 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100713 Thunderbird/3.0.6

Hi Carsten,

On 22.07.2010 09:38, Carsten Dominik wrote:
> Hi Martin,
> On Jul 21, 2010, at 4:32 PM, Carsten Dominik wrote:
>> Hi Martin,
>> I just looked at your patch.
>> If I have a normal agenda (i.e. *not* a block agenda), then your
>> patch will cause the preset filter *not* to be applied.
> OK, that was obviously incorrect, sorry about that.
> However, it still does not work correctly, here is the counter example:
> -----------------------------------------------------------------------------
> * TODO test 1                                                           :a:
> * TODO test 2                                                           :b:
> * at 1                                                                        
>   :a:
>    SCHEDULED: <2010-07-22 Thu>
> * at 1                                                                        
>   :b:
>    SCHEDULED: <2010-07-22 Thu>
> ------------------------------------------------------------------------------

Here is what I found to be incorrect.

* For unmodified org-mode, this ignores the org-agenda-filter-preset.
  Is this what you mean or is anything else broken?

* For my patched version, too much is hidden and only revealed after
  clearing the global filter.  Did you mean anything else?

> With this custom command:
> (setq org-agenda-custom-commands
>        '(("x" "testmartin"
>        ((agenda "" ((org-agenda-filter-preset '("+a"))))
>         (alltodo "" ((org-agenda-filter-preset '("+b")))))
>        nil nil)))
> the result is incorrect, both with and without your patch.

But in different ways, as state above.

> The internal logic of the filter and the preset filter is such that
> it applies to the entire view, and you should not set in the local
> options for a command that is part of a block agenda view.

Well, it is already partly there in that local filters are stored in
text properties for each line.  Maybe we can extend this a bit to remove
this limitation?

I will look into it if I have more time.


reply via email to

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