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

["sgeorgii ." <sgeorgii@gmail.com>]

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 <kyle@kyleam.com> wrote:
> Hello,
>
> "sgeorgii ." <sgeorgii@gmail.com> 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