[Top][All Lists]

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

Re: [O] Unable to filter agenda to show only non-tagged items

From: sgeorgii .
Subject: Re: [O] Unable to filter agenda to show only non-tagged items
Date: Wed, 25 Nov 2015 10:53:43 +0300

Thank you Kyle. I wrote to that tread - hope they might be able to help me.
Regarding the above behavior being documented - I believe not. The
reason I believe it does not require specific documentation. Because
this is default behavior to filter by empty tag. How else would one
filter to get only non-tagged items in agenda? This way came to me
naturally and I used it ever since until it stopped working in recent
version of Org. Hope someone could get this use case incorporated or
advice on another way of filtering only non-tagged items in agenda.

On 24 November 2015 at 19:39, Kyle Meyer <address@hidden> wrote:
> Hello,
> "sgeorgii ." <address@hidden> writes:
>> Hello!
>> Having installed latest org 8.3.2 I am now having the subject problem:
>> M-x org-agenda
>> When in agenda:
>> / (filter)
>> TAB (filter by tag)
>> <Enter> (without entering any tags for "Tag:" question)
>> Before this gave me agenda view filtered to show only non-tagged items.
>> I believe this was right and just fine.
>> Now I have error:
>> Debugger entered--Lisp error: (args-out-of-range "" 0 1)
>>   org-agenda-filter-make-matcher-tag-exp(("+") 43)
>>   org-agenda-filter-make-matcher(("+") tag t)
>>   org-agenda-filter-apply(("+") tag t)
>>   org-agenda-filter-by-tag(nil)
>>   call-interactively(org-agenda-filter-by-tag nil nil)
>>   command-execute(org-agenda-filter-by-tag)
> I believe 6c6ae99 (org-agenda: Filtering in the agenda on grouptags,
> 2015-01-24) changed this behavior.  The discussion about these changes
> is here (sorry, the gmane web interface is down for me):
> https://lists.gnu.org/archive/html/emacs-orgmode/2015-01/msg00618.html
> org-agenda-filter-by-tag should be fixed to handle the empty tag case
> that causes the error above, either by behaving as before or by giving a
> clear error.  I haven't looked closely enough at the changes or the
> discussion to guess whether that commit intended to preserve the empty
> tag behavior you were relying on.  Is that behavior documented anywhere?
> --
> Kyle

reply via email to

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