Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Nicolas Goaziou]

Gustav Wikström  writes:

> Taking your comments and improving the first patch a bit resulted in
> the attached one. It replaces the previous. Using string-prefix-p and
> string-suffix-p solves the out of index problem in the substrings.

Applied. Thank you.

I modified a bit the patch however, since my suggestion about using
`string-suffix-p' doesn't hold: it isn't compatible with Emacs 24.3.
I also removed a bunch of `setq'.


Regards,

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi,

> -Original Message-
> From: Nicolas Goaziou [mailto:m...@nicolasgoaziou.fr]
> Sent: Thursday, November 26, 2015 09:22
> To: Gustav Wikström 
> Cc: sgeorgii . ; emacs-orgmode@gnu.org
> Subject: Re: [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps
> 
> Gustav Wikström  writes:
> 
> > Taking your comments and improving the first patch a bit resulted in
> > the attached one. It replaces the previous. Using string-prefix-p and
> > string-suffix-p solves the out of index problem in the substrings.

Ok, darnit. And I see you found another workaround for that ;-)

> 
> Applied. Thank you.

Great.

> 
> I modified a bit the patch however, since my suggestion about using `string-
> suffix-p' doesn't hold: it isn't compatible with Emacs 24.3.
> I also removed a bunch of `setq'.

Ok, fair enough. A bit more difficult to follow the code now (in my opinion) 
but I guess it saves a few I/O's. 

There was a small error in your edit though. The push-statement feels lonely 
outside of the let*.

> 
> 
> Regards,

Kind regards
Gustav

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Nicolas Goaziou]

Gustav Wikström  writes:

> Ok, fair enough. A bit more difficult to follow the code now (in my
> opinion)

I honestly don't think so. Of course, YMMV.

> but I guess it saves a few I/O's.

If `setq' can be avoided (assuming a context of lexical binding) it's
better, indeed.

> There was a small error in your edit though. The push-statement feels
> lonely outside of the let*.

Duh. Fixed. Thank you.

Regards,

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi,

Taking your comments and improving the first patch a bit resulted in the 
attached one. It replaces the previous. Using string-prefix-p and 
string-suffix-p solves the out of index problem in the substrings.

BR
Gustav 

> -Original Message-
> From: Nicolas Goaziou [mailto:m...@nicolasgoaziou.fr]
> Sent: Wednesday, November 25, 2015 15:53
> To: Gustav Wikström <gus...@whil.se>
> Cc: emacs-orgmode@gnu.org; sgeorgii . <sgeor...@gmail.com>
> Subject: Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and
> regexps
> 
> Gustav Wikström <gus...@whil.se> writes:
> 
> > Hmm, since the error was thrown when trying to look at indexes outside
> > of the string in (substring ... ), I don't see how isregexp can be
> > left as is. We have to make sure the substring-code is not evaluated
> > if the tag is empty. What am I missing?
> 
> Nothing, I was clear as mud.
> 
>   (cond
>((string= "" tag) (setq f1 '(not tags)))
>((and (equal "{" ...)
>  (equal "}"...))
> ...)
>(t ...))
> 
> Or even
> 
>  ((and (string-prefix-p "{" ...)
>(string-suffix-p "}" ...)))
> 
> on master.
> 
> Regards,


0001-org-agenda-Filter-empty-tags.patch
Description: 0001-org-agenda-Filter-empty-tags.patch

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[sgeorgii .]

>From my side I confirm the second patch works fine for me so far on
current org-mode.

Thank you Gustav, Nikolas!

Any chance for this patch to go upstream, please?

On 25 November 2015 at 18:39, Gustav Wikström <gus...@whil.se> wrote:
> Hi,
>
> Taking your comments and improving the first patch a bit resulted in the 
> attached one. It replaces the previous. Using string-prefix-p and 
> string-suffix-p solves the out of index problem in the substrings.
>
> BR
> Gustav
>
>> -Original Message-
>> From: Nicolas Goaziou [mailto:m...@nicolasgoaziou.fr]
>> Sent: Wednesday, November 25, 2015 15:53
>> To: Gustav Wikström <gus...@whil.se>
>> Cc: emacs-orgmode@gnu.org; sgeorgii . <sgeor...@gmail.com>
>> Subject: Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and
>> regexps
>>
>> Gustav Wikström <gus...@whil.se> writes:
>>
>> > Hmm, since the error was thrown when trying to look at indexes outside
>> > of the string in (substring ... ), I don't see how isregexp can be
>> > left as is. We have to make sure the substring-code is not evaluated
>> > if the tag is empty. What am I missing?
>>
>> Nothing, I was clear as mud.
>>
>>   (cond
>>((string= "" tag) (setq f1 '(not tags)))
>>((and (equal "{" ...)
>>  (equal "}"...))
>> ...)
>>(t ...))
>>
>> Or even
>>
>>  ((and (string-prefix-p "{" ...)
>>(string-suffix-p "}" ...)))
>>
>> on master.
>>
>> Regards,

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Nicolas Goaziou]

Gustav Wikström  writes:

> Hmm, since the error was thrown when trying to look at indexes outside
> of the string in (substring ... ), I don't see how isregexp can be
> left as is. We have to make sure the substring-code is not evaluated
> if the tag is empty. What am I missing?

Nothing, I was clear as mud.

  (cond
   ((string= "" tag) (setq f1 '(not tags)))
   ((and (equal "{" ...)
 (equal "}"...))
...)
   (t ...))

Or even

 ((and (string-prefix-p "{" ...)
   (string-suffix-p "}" ...)))

on master.

Regards,

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi, see below

> >
> > * lisp/org-agenda.el (org-agenda-filter-make-matcher-tag-exp): Deal with
> >   the case when the user provided an empty string to filter or exclude
> >   rows from the agenda.
> 
> Please provide a reference to the discussion that lead to this patch.

The reference being the subject-line and date of the mail from sgeorgii?

> 
> >(let* ((tag (substring x 1))
> > -(isregexp (and (equal "{" (substring tag 0 1))
> > +(isemptystring (string= "" tag))
> > +(isregexp (and (not isemptystring)
> > +   (equal "{" (substring tag 0 1))
> > (equal "}" (substring tag -1
> >  regexp)
> > (cond
> >  (isregexp
> >   (setq regexp (substring tag 1 -1))
> >   (setq f1 (list 'org-match-any-p regexp 'tags)))
> > +(isemptystring
> > + (setq f1 '(not tags)))
> >  (t
> >   (setq f1 (list 'member (downcase tag) 'tags
> > (when (eq op ?-)
> 
> Nitpick time:
> 
> You don't need isemptystring if it is the first branch in cond
> 
>   (cond
>((string= "" tag) (setq f1 '(not tags)))
>(isregexp ...)
>(t ...))
> 
> Obviously, in that case, you don't need to change isregexp at all.

Hmm, since the error was thrown when trying to look at indexes outside of the 
string in (substring ... ), I don't see how isregexp can be left as is. We have 
to make sure the substring-code is not evaluated if the tag is empty. What am I 
missing? 

> 
> 
> Regards,
> 
> --
> Nicolas Goaziou0x80A93738

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi!

Indeed, I do get the same error as you. I'll look into it a bit. Not sure if 
the behavior is documented though.

As a workaround for you sgeorgii (and for everyone else with this problem I 
suppose :-) ), you can exclude tags instead of filtering. The behavior is 
similar except instead of only showing the rows with the provided tag, it 
excludes all rows with the provided tag. If you provide a regular expression, 
eg. {.*}, then all rows with tags are hidden from the agenda-view.

So, to recreate with commands, what I just tried to describe with words:
M-x org-agenda
\ (exclude) (alternatively use the combination of / (filter) - (exclude) )
 (exclude by tag)
{.*}


Voila!

Best regards
Gustav

> -Original Message-
> From: sgeorgii . [mailto:sgeor...@gmail.com]
> Sent: Wednesday, November 25, 2015 08:51
> To: gustav.e...@gmail.com; m...@nicolasgoaziou.fr; emacs-
> orgm...@gnu.org
> Subject: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps
> 
> Dear Gustav, Eric,
> 
> 
> I was referred to your subject discussion in respect to my problem:
> 
> With new version of org-mode I am now unable to filter agenda to show only
> non-tagged items:
> 
> 
> > "sgeorgii ." <sgeor...@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)
> >>
> >>  (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
> 
> 
> Any help?

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[sgeorgii .]

Indeed, the {.*} works. Thank you!

If we could still use the empty parameter when filtering by "no tags"
it would be really sweet :)

On 25 November 2015 at 13:26, Gustav Wikström <gus...@whil.se> wrote:
> Hi!
>
> Indeed, I do get the same error as you. I'll look into it a bit. Not sure if 
> the behavior is documented though.
>
> As a workaround for you sgeorgii (and for everyone else with this problem I 
> suppose :-) ), you can exclude tags instead of filtering. The behavior is 
> similar except instead of only showing the rows with the provided tag, it 
> excludes all rows with the provided tag. If you provide a regular expression, 
> eg. {.*}, then all rows with tags are hidden from the agenda-view.
>
> So, to recreate with commands, what I just tried to describe with words:
> M-x org-agenda
> \ (exclude) (alternatively use the combination of / (filter) - (exclude) )
>  (exclude by tag)
> {.*}
> 
>
> Voila!
>
> Best regards
> Gustav
>
>> -Original Message-
>> From: sgeorgii . [mailto:sgeor...@gmail.com]
>> Sent: Wednesday, November 25, 2015 08:51
>> To: gustav.e...@gmail.com; m...@nicolasgoaziou.fr; emacs-
>> orgm...@gnu.org
>> Subject: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps
>>
>> Dear Gustav, Eric,
>>
>>
>> I was referred to your subject discussion in respect to my problem:
>>
>> With new version of org-mode I am now unable to filter agenda to show only
>> non-tagged items:
>>
>>
>> > "sgeorgii ." <sgeor...@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)
>> >>
>> >>  (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
>>
>>
>> Any help?

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi again,

Patch attached. 

If someone could apply it I'd be glad.

Best Regards
Gustav

> -Original Message-
> From: sgeorgii . [mailto:sgeor...@gmail.com]
> Sent: Wednesday, November 25, 2015 12:05
> To: Gustav Wikström <gus...@whil.se>
> Cc: m...@nicolasgoaziou.fr; emacs-orgmode@gnu.org
> Subject: Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and
> regexps
> 
> Indeed, the {.*} works. Thank you!
> 
> If we could still use the empty parameter when filtering by "no tags"
> it would be really sweet :)
> 
> On 25 November 2015 at 13:26, Gustav Wikström <gus...@whil.se> wrote:
> > Hi!
> >
> > Indeed, I do get the same error as you. I'll look into it a bit. Not sure 
> > if the
> behavior is documented though.
> >
> > As a workaround for you sgeorgii (and for everyone else with this problem I
> suppose :-) ), you can exclude tags instead of filtering. The behavior is 
> similar
> except instead of only showing the rows with the provided tag, it excludes all
> rows with the provided tag. If you provide a regular expression, eg. {.*}, 
> then all
> rows with tags are hidden from the agenda-view.
> >
> > So, to recreate with commands, what I just tried to describe with words:
> > M-x org-agenda
> > \ (exclude) (alternatively use the combination of / (filter) -
> > (exclude) )  (exclude by tag) {.*} 
> >
> > Voila!
> >
> > Best regards
> > Gustav
> >
> >> -Original Message-
> >> From: sgeorgii . [mailto:sgeor...@gmail.com]
> >> Sent: Wednesday, November 25, 2015 08:51
> >> To: gustav.e...@gmail.com; m...@nicolasgoaziou.fr; emacs-
> >> orgm...@gnu.org
> >> Subject: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and
> >> regexps
> >>
> >> Dear Gustav, Eric,
> >>
> >>
> >> I was referred to your subject discussion in respect to my problem:
> >>
> >> With new version of org-mode I am now unable to filter agenda to show
> >> only non-tagged items:
> >>
> >>
> >> > "sgeorgii ." <sgeor...@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)
> >> >>
> >> >>  (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.h
> >> > tml
> >> >
> >> > 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
> >>
> >>
> >> Any help?


0001-org-agenda-Filter-empty-tags.patch
Description: 0001-org-agenda-Filter-empty-tags.patch

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Nicolas Goaziou]

Hello,

Gustav Wikström  writes:

> Patch attached.

Thank you. A minor comment below.

> From 445995e1fad646b2b22c014e09e3e05a7aeeede1 Mon Sep 17 00:00:00 2001
> From: Gustav Wikstrom 
> Date: Wed, 25 Nov 2015 13:06:31 +0100
> Subject: [PATCH] org-agenda: Filter empty tags
>
> * lisp/org-agenda.el (org-agenda-filter-make-matcher-tag-exp): Deal with
>   the case when the user provided an empty string to filter or exclude
>   rows from the agenda.

Please provide a reference to the discussion that lead to this patch.

>(let* ((tag (substring x 1))
> -  (isregexp (and (equal "{" (substring tag 0 1))
> +  (isemptystring (string= "" tag))
> +  (isregexp (and (not isemptystring)
> + (equal "{" (substring tag 0 1))
>   (equal "}" (substring tag -1
>regexp)
>   (cond
>(isregexp
> (setq regexp (substring tag 1 -1))
> (setq f1 (list 'org-match-any-p regexp 'tags)))
> +  (isemptystring
> +   (setq f1 '(not tags)))
>(t
> (setq f1 (list 'member (downcase tag) 'tags
>   (when (eq op ?-)

Nitpick time:

You don't need isemptystring if it is the first branch in cond

  (cond
   ((string= "" tag) (setq f1 '(not tags)))
   (isregexp ...)
   (t ...))

Obviously, in that case, you don't need to change isregexp at all.


Regards,

-- 
Nicolas Goaziou0x80A93738

[O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[sgeorgii .]

Dear Gustav, Eric,


I was referred to your subject discussion in respect to my problem:

With new version of org-mode I am now unable to filter agenda to show
only non-tagged items:


> "sgeorgii ."  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)
>>
>>  (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


Any help?

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Nicolas Goaziou]

Gustav Wikström gustav.e...@gmail.com writes:

 I don't mind. Wrote a few lines and the patch is attached!

Applied. Thank you.

Regards,

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Nicolas Goaziou m...@nicolasgoaziou.fr wrote:

 As a final step, would you mind preparing an entry in ORG-NEWS? I think
 most of it can be extracted from your commit messages.

I don't mind. Wrote a few lines and the patch is attached!

Best regards
Gustav


0001-ORG-NEWS-Mention-change-in-grouptags-functionality.patch
Description: Binary data

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi again!

Comments below.

 From: Nicolas Goaziou [mailto:m...@nicolasgoaziou.fr]

  +(taggroups (if downcased (mapcar (lambda (tg) (mapcar #'downcase 
  tg))
  + taggroups) taggroups))
 
 Nitpick: indentation

Can't see what's wrong.. Autoindent by emacs did this. Anyways.. I made the 
if-construct clearer by adding linebreaks.

  +   (delq nil (mapcar (lambda (x)
  +   (if (stringp x)
  +   (and (equal { (substring x 0 1))
  +(equal } (substring x -1))
  +x)
  + x)) tags-in-group))
 
 Same here. TAGS-IN-GROUP should be at the same level as (lambda (x) ...)

Ok, fixed.

  +   regexp-in-group
  +   (mapcar (lambda (x)
  + (substring x 1 -1)) regexp-in-group-escaped)
 
 Ditto.

Fixed.

  +   tags-in-group
  +   (delq nil (mapcar (lambda (x)
  +   (if (stringp x)
  +   (and (not (equal { (substring x 0 
  1)))
  +(not (equal } (substring x 
  -1)))
  +x)
  +  x)) 
  tags-in-group)))
 
 Ditto.

Fixed.

  + ; If single-as-list, do no more in the while-loop...
  + (if (not single-as-list)
  + (progn
  +   (if regexp-in-group
  +   (setq regexp-in-group (concat \\| (mapconcat 
  'identity regexp-in-group \\|
  +   (setq tags-in-group (concat dir {\\ (regexp-opt 
  tags-in-group) regexp-in-group  \\}))
 
 You need to keep lines within 80 columns.

Trying to avoid it.

  + (when (member tg g)
  +   (mapc (lambda (x)
  +   (setq current (delete x current)))
  + g)))
 
 While you're at it:
 
   (when (member tg g) (dolist (x g) (setq current (delete x current

Ok!

  +(defun org-agenda-filter-by-tag (arg optional char exclude)
 Keep only those lines in the agenda buffer that have a specific tag.
   The tag is selected with its fast selection letter, as configured.
  -With prefix argument STRIP, remove all lines that do have the tag.
  -A lisp caller can specify CHAR.  NARROW means that the new tag should be
  -used to narrow the search - the interactive user can also press `-' or `+'
  -to switch to narrowing.
  +With a single `C-u' prefix ARG, exclude the agenda search.  With a
  +double `C-u' prefix ARG, filter the literal tag. I.e. don't filter on
   ^^^
  missing space

Fixed.

 Also, instead of hard-coding `C-u', you could use \\[universal-argument]
 within the doc string. See, for example, `org-tree-to-indirect-buffer'.

Fixed.

  +(exclude (if exclude exclude (equal arg '(4
 
   (exclude (or exclude (equal arg '(4

Fixed.
 
  +  (while (not (memq char (append '(?\t ?\r ?/ ?. ?\ ?q)
  +(string-to-list tag-chars
 
 For clarity, use ?\s instead of ?\

Fixed.

 Also, I suggest to move the consing before the while loop.

Good point, changed.

  + ((eq char ?. )
 
 Spurious space.

Fixed.

  + ((or (eq char ?\ )
 
 See above.

Fixed.

 
  + (save-match-data
  +   (let (tags-expanded)
  + (dolist (x (cdr tags-in-group))
  +   (if (and (member x taggroups-keys)
  +(not (member x work-already-expanded)))
  +   (setq tags-expanded (delete-dups
  +(append (org-tags-expand x t 
  downcased work-already-expanded)
  +tags-expanded)))
  + (setq tags-expanded (append (list x) tags-expanded)))
  +   (setq work-already-expanded (delete-dups (append 
  tags-expanded work-already-expanded
  + (setq tags-in-group (delete-dups (cons (car tags-in-group)
  +
  tags-expanded)
 
 Lines too wide.

Ok, fixed kind of. I don't want to compromise on the relatively long variable 
names.

 
  +Tags can be defined in hierarchies. A tag can be defined as a @emph{group
  ^^^
   missing space

Fixed.

   @lisp
  -(setq org-tag-alist '((:startgroup . nil)
  +(setq org-tag-alist '((:startgrouptag . nil)
 (@@read . nil)
 (:grouptags . nil)
 (@@read_book . nil)
 (@@read_ebook . nil)
  -  (:endgroup . nil)))
  +  (:endgrouptag . nil)))
   @end lisp
 

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Nicolas Goaziou]

Gustav Wikström gustav.e...@gmail.com writes:

 Fixed patches are attached,

Applied. Thank you.

As a final step, would you mind preparing an entry in ORG-NEWS? I think
most of it can be extracted from your commit messages.

Regards,

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi again!

It seems my mail got stuck in some filters - I sent one from another
address yesterday. Oh well, here it is anyway!

Comments below.

 From: Nicolas Goaziou [mailto:m...@nicolasgoaziou.fr]

  + (taggroups (if downcased (mapcar (lambda (tg) (mapcar #'downcase tg))
  +  taggroups) taggroups))

 Nitpick: indentation

Can't see what's wrong.. Autoindent by emacs did this. Anyways.. I
made the if-construct clearer by adding linebreaks.

  +(delq nil (mapcar (lambda (x)
  + (if (stringp x)
  +(and (equal { (substring x 0 1))
  + (equal } (substring x -1))
  + x)
  +  x)) tags-in-group))

 Same here. TAGS-IN-GROUP should be at the same level as (lambda (x) ...)

Ok, fixed.

  +regexp-in-group
  +(mapcar (lambda (x)
  +  (substring x 1 -1)) regexp-in-group-escaped)

 Ditto.

Fixed.

  +tags-in-group
  +(delq nil (mapcar (lambda (x)
  + (if (stringp x)
  +(and (not (equal { (substring x 0 1)))
  + (not (equal } (substring x -1)))
  + x)
  +   x)) tags-in-group)))

 Ditto.

Fixed.

  +  ; If single-as-list, do no more in the while-loop...
  +  (if (not single-as-list)
  +  (progn
  +(if regexp-in-group
  + (setq regexp-in-group (concat \\| (mapconcat 'identity regexp-in-group 
  \\|
  +(setq tags-in-group (concat dir {\\ (regexp-opt tags-in-group) 
  regexp-in-group  \\}))

 You need to keep lines within 80 columns.

Trying to avoid it.

  +  (when (member tg g)
  +(mapc (lambda (x)
  +(setq current (delete x current)))
  +  g)))

 While you're at it:

   (when (member tg g) (dolist (x g) (setq current (delete x current

Ok!

  +(defun org-agenda-filter-by-tag (arg optional char exclude)
 Keep only those lines in the agenda buffer that have a specific tag.
   The tag is selected with its fast selection letter, as configured.
  -With prefix argument STRIP, remove all lines that do have the tag.
  -A lisp caller can specify CHAR.  NARROW means that the new tag should be
  -used to narrow the search - the interactive user can also press `-' or `+'
  -to switch to narrowing.
  +With a single `C-u' prefix ARG, exclude the agenda search.  With a
  +double `C-u' prefix ARG, filter the literal tag. I.e. don't filter on
   ^^^
  missing space

Fixed.

 Also, instead of hard-coding `C-u', you could use \\[universal-argument]
 within the doc string. See, for example, `org-tree-to-indirect-buffer'.

Fixed.

  + (exclude (if exclude exclude (equal arg '(4

   (exclude (or exclude (equal arg '(4

Fixed.

  +  (while (not (memq char (append '(?\t ?\r ?/ ?. ?\ ?q)
  + (string-to-list tag-chars

 For clarity, use ?\s instead of ?\

Fixed.

 Also, I suggest to move the consing before the while loop.

Good point, changed.

  + ((eq char ?. )

 Spurious space.

Fixed.

  + ((or (eq char ?\ )

 See above.

Fixed.


  +  (save-match-data
  +(let (tags-expanded)
  +  (dolist (x (cdr tags-in-group))
  + (if (and (member x taggroups-keys)
  + (not (member x work-already-expanded)))
  +(setq tags-expanded (delete-dups
  + (append (org-tags-expand x t downcased work-already-expanded)
  + tags-expanded)))
  +  (setq tags-expanded (append (list x) tags-expanded)))
  + (setq work-already-expanded (delete-dups (append tags-expanded 
  work-already-expanded
  +  (setq tags-in-group (delete-dups (cons (car tags-in-group)
  +
  tags-expanded)

 Lines too wide.

Ok, fixed kind of. I don't want to compromise on the relatively long
variable names.


  +Tags can be defined in hierarchies. A tag can be defined as a @emph{group
  ^^^
   missing space

Fixed.

   @lisp
  -(setq org-tag-alist '((:startgroup . nil)
  +(setq org-tag-alist '((:startgrouptag . nil)
 (@@read . nil)
 (:grouptags . nil)
 (@@read_book . nil)
 (@@read_ebook . nil)
  -  (:endgroup . nil)))
  +  (:endgrouptag . nil)))
   @end lisp

 The following is clearer

   @lisp
   (setq org-tag-alist '((:startgrouptag)
 (@@read)
 (:grouptags)
 (@@read_book)
 (@@read_ebook)
 (:endgrouptag)))
   @end lisp


Indeed

 However, shouldn't this example apply to the one above? (e.g.., with
 Control : Context Task tag line)?

Indeed again!


  +Searching for the tag Project will now list all tags also including regular
  +expression matches for P@@.+.  Similar for tag-searches on Vision, Goal and
  +AOF.  This can be good for example if tags for a certain project is tagged
  +with a common project-identifier, i.e. P@@2014_OrgTags.

 @samp{Project} @samp{Vision}... @samp{P@@2014_OrgTags}.

 This all looks very nice.

Thx!

 As a final 

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Nicolas Goaziou]

Gustav Wikström gustav.e...@gmail.com writes:

 I've fixed the issues raised (IMO), and new patches are attached. I've
 added a patch for documentation also.

Thank you.

 I'd say it's an unnecessary limitation if group tags have to be
 exclusive on a headline. The more general case should be allowed and I
 can see use-cases for it.

 If you, for example, want to create a taxonomy of your tags and a part
 of your taxonomy is this:

 #+TAGS: [ CS : DB OS Software Versioning Programming BI ]

 What reason is there for Org mode to limit me to only choosing one of
 the above? Lets say I find an article on the web and want to create a
 node in my org-mode repository about it. Maybe linking the article and
 adding a few thoughts. The fictive article may be called the
 importance of good database-design in Business intelligence. It seems
 two tags of the above would fit just fine; DB  BI.

Fair enough.

 +  (taggroups (if downcased (mapcar (lambda (tg) (mapcar #'downcase 
 tg))
 +   taggroups) taggroups))

Nitpick: indentation

(taggroups (if downcased
   (mapcar (lambda (tg) (mapcar #'downcase tg)) taggroups) 
 taggroups))

 + (delq nil (mapcar (lambda (x)
 + (if (stringp x)
 + (and (equal { (substring x 0 1))
 +  (equal } (substring x -1))
 +  x)
 +   x)) tags-in-group))

Same here. TAGS-IN-GROUP should be at the same level as (lambda (x) ...)

 + regexp-in-group
 + (mapcar (lambda (x)
 +   (substring x 1 -1)) regexp-in-group-escaped)

Ditto.

 + tags-in-group
 + (delq nil (mapcar (lambda (x)
 + (if (stringp x)
 + (and (not (equal { (substring x 0 
 1)))
 +  (not (equal } (substring x 
 -1)))
 +  x)
 +x)) 
 tags-in-group)))

Ditto.

 +   ; If single-as-list, do no more in the while-loop...
 +   (if (not single-as-list)
 +   (progn
 + (if regexp-in-group
 + (setq regexp-in-group (concat \\| (mapconcat 
 'identity regexp-in-group \\|
 + (setq tags-in-group (concat dir {\\ (regexp-opt 
 tags-in-group) regexp-in-group  \\}))

You need to keep lines within 80 columns.

 +   (when (member tg g)
 + (mapc (lambda (x)
 + (setq current (delete x current)))
 +   g)))

While you're at it:

  (when (member tg g) (dolist (x g) (setq current (delete x current

 +(defun org-agenda-filter-by-tag (arg optional char exclude)
Keep only those lines in the agenda buffer that have a specific tag.
  The tag is selected with its fast selection letter, as configured.
 -With prefix argument STRIP, remove all lines that do have the tag.
 -A lisp caller can specify CHAR.  NARROW means that the new tag should be
 -used to narrow the search - the interactive user can also press `-' or `+'
 -to switch to narrowing.
 +With a single `C-u' prefix ARG, exclude the agenda search.  With a
 +double `C-u' prefix ARG, filter the literal tag. I.e. don't filter on
  ^^^
 missing space

Also, instead of hard-coding `C-u', you could use \\[universal-argument]
within the doc string. See, for example, `org-tree-to-indirect-buffer'.

 +  (exclude (if exclude exclude (equal arg '(4

  (exclude (or exclude (equal arg '(4

 +  (while (not (memq char (append '(?\t ?\r ?/ ?. ?\ ?q)
 +  (string-to-list tag-chars

For clarity, use ?\s instead of ?\

Also, I suggest to move the consing before the while loop.

 + ((eq char ?. )

Spurious space.

 + ((or (eq char ?\ )

See above.

 +   (save-match-data
 + (let (tags-expanded)
 +   (dolist (x (cdr tags-in-group))
 + (if (and (member x taggroups-keys)
 +  (not (member x work-already-expanded)))
 + (setq tags-expanded (delete-dups
 +  (append (org-tags-expand x t 
 downcased work-already-expanded)
 +  tags-expanded)))
 +   (setq tags-expanded (append (list x) tags-expanded)))
 + (setq work-already-expanded (delete-dups (append 
 tags-expanded work-already-expanded
 +   (setq tags-in-group (delete-dups (cons (car tags-in-group)
 

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi, and thanks for the extensive comments!

I've fixed the issues raised (IMO), and new patches are attached. I've
added a patch for documentation also.

 ,
 | #+TAGS: { group : include1 include2 }
 `

 will only allow one of the tags on any specific headline. [ ] solves
 this. Note that grouptags doesn't care if { } or [ ] is used. The only
 difference is the exclusiveness. I.e both

 ,
 | #+TAGS: [ group : include1 include2 ]
 | #+TAGS: { group : include1 include2 }
 `

 will work. With some limitations on the second example due to the way {
 } works since before.

 OK, but is it really needed? What is the point of having two tags of the
 same group (or, if we consider nested group tags, the same set of
 siblings) at the same time?

I'd say it's an unnecessary limitation if group tags have to be
exclusive on a headline. The more general case should be allowed and I
can see use-cases for it.

If you, for example, want to create a taxonomy of your tags and a part
of your taxonomy is this:

#+TAGS: [ CS : DB OS Software Versioning Programming BI ]

What reason is there for Org mode to limit me to only choosing one of
the above? Lets say I find an article on the web and want to create a
node in my org-mode repository about it. Maybe linking the article and
adding a few thoughts. The fictive article may be called the
importance of good database-design in Business intelligence. It seems
two tags of the above would fit just fine; DB  BI.

Best regards
Gustav


0001-org-Grouptags-not-unique-and-can-contain-regexp.patch
Description: Binary data


0002-org-agenda-Filtering-in-the-agenda-on-grouptags.patch
Description: Binary data


0003-org-Nesting-grouptags.patch
Description: Binary data


0004-org.texi-Complement-info-for-group-tags.patch
Description: Binary data

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Nicolas Goaziou]

Gustav Wikström gustav.e...@gmail.com writes:

 Hi again! The FSA-assignment is now complete. New patches are attached
 and comments below.

OK. I updated list of contributors accordingly.

 The reason for the use of [ ] is because { } already has another purpose
 - it is used to make the tags within { } exclusive.

 this example

 ,
 | #+TAGS: { group : include1 include2 }
 `

 will only allow one of the tags on any specific headline. [ ] solves
 this. Note that grouptags doesn't care if { } or [ ] is used. The only
 difference is the exclusiveness. I.e both

 ,
 | #+TAGS: [ group : include1 include2 ]
 | #+TAGS: { group : include1 include2 }
 `

 will work. With some limitations on the second example due to the way {
 } works since before.

OK, but is it really needed? What is the point of having two tags of the
same group (or, if we consider nested group tags, the same set of
siblings) at the same time?

 Subject: [PATCH 1/3] org: Grouptags not unique and can contain regexp

 * lisp/org.el (org--setup-process-tags):
   (org-fast-tag-selection):

   Grouptags had to previously be defined with { }. This syntax is
   already used for exclusive tags and Grouptags need their own,
   non-exclusive syntax. This behaviour is achieved with [ ]
   instead. Note: { } can still be used also for Grouptags but then
   only one of the given tags can be used on the headline at the same
   time. Example:

You need to separate sentences with two spaces.  Also, commit messages
need to be formatted this way

 * lisp/org.el (function): Small description.
   (other function): Small description.

 Long explanations.

 -(org-re \\`\\([[:alnum:]_@#%]+\\)\\(?:(\\(.\\))\\)?\\') e)
 +(org-re (concat \\`\\([[:alnum:]_@#%]+
 +\\|{.+}\\) ; regular expression
   ^^^
I think it should be non-greedy above.

 +  (taggroups (or org-tag-groups-alist-for-agenda 
 org-tag-groups-alist))
 +  (taggroups (if downcased (mapcar (lambda(tg) (mapcar 'downcase 
 tg)) taggroups) taggroups))

Nitpick:

  (lambda (tg) ... #'downcase ...)

Also it should be wrapped at 80 characters.

 +  (taggroups-keys (mapcar 'car taggroups))

Nitpick: (mapcar #'car taggroups)

 +  (return-match (if downcased (downcase match) match))
 +  (count 0)
 +  regexps-in-match tags-in-group regexp-in-group 
 regexp-in-group-escaped)
   ;; @ and _ are allowed as word-components in tags
   (modify-syntax-entry ?@ w stable)
   (modify-syntax-entry ?_ w stable)
 - (while (and tml
 + ;; Temporarily replace regexp-expressions in the match-expression

Nitpick: missing full stop.

 + (while (string-match {.+?} return-match)
 +   (setq count (1+ count))

Nitpick:

  (incf count)

 +   (setq regexps-in-match (cons (match-string 0 return-match) 
 regexps-in-match))

Nitpick:

  (push (match-string 0 return-match) regexps-in-match)

 +   (setq return-match (replace-match (concat  (number-to-string 
 count) ) t nil return-match)))

Nitpick:

  (format %d count)

 +   ; Filter tag-regexps from tags
 +   (setq regexp-in-group-escaped (delq nil (mapcar (lambda (x)
 + (if (stringp x)
 + (and 
 (string-prefix-p { x)
 +  
 (string-suffix-p } x)
 +  x)
 +   x)) 
 tags-in-group))

We cannot use `string-prefix-p' and `string-suffix-p' due to backward
compatibility. The former will be fine in Org 8.4 (it was introduced in
Emacs 24.1), but the latter comes from Emacs 24.4.

You can use (equal (substring x ... ...) ...) instead.

Be careful about line width, too.

 + tags-in-group (delq nil (mapcar (lambda (x)
 +   (if (stringp x)
 +   (and (not 
 (string-prefix-p { x))
 +(not 
 (string-suffix-p } x))
 +x)
 + x)) tags-in-group)))

Ditto.

 +   ; If single-as-list, do no more in the while-loop...
 +   (if (not single-as-list)
 +   (progn
 + (if regexp-in-group
 + (setq regexp-in-group (concat \\| (mapconcat 
 'identity regexp-in-group \\|
 + (setq tags-in-group (concat dir {\\ (regexp-opt 
 tags-in-group) regexp-in-group  \\}))
 + (if (stringp tags-in-group) (org-add-props tags-in-group 
 '(grouptag t)))

Nitpick: (when (stringp tags-in-group) ...)

 + (setq return-match (replace-match tags-in-group t t 
 

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi again! The FSA-assignment is now complete. New patches are attached
and comments below.

On Sat, Jan 31, 2015 at 9:41 AM, Nicolas Goaziou m...@nicolasgoaziou.fr wrote:

 I suppose an FSF-assignment signature is needed before it can be
 included.

 Indeed.

Marked as done now, as stated above :-)

 - Grouptags don't have to be unique on a headline if added with [ ]
   instead of with { }: , | #+TAGS: [ group : include1 included2 ]
   `

 I'd rather not introduce yet another syntax for group tags. IIUC, the
 current one (with curly braces) can be extended.

 Also, I don't get the have to be unique on a headline part.

The reason for the use of [ ] is because { } already has another purpose
- it is used to make the tags within { } exclusive.

this example

,
| #+TAGS: { group : include1 include2 }
`

will only allow one of the tags on any specific headline. [ ] solves
this. Note that grouptags doesn't care if { } or [ ] is used. The only
difference is the exclusiveness. I.e both

,
| #+TAGS: [ group : include1 include2 ]
| #+TAGS: { group : include1 include2 }
`

will work. With some limitations on the second example due to the way {
} works since before.

   A new variable is defined `ORG-GROUP-TAGS-MAX-DEPTH' that is used
   to limit the depth of recursion when expanding tags. It defaults to
   2.

 I don't think this variable is necessary. However, a check for
 circular inclusions would be necessary.

Indeed. The variable is removed and the function `org-tags-expand' now
handles circular definitions with grace ;-)

Best regards
Gustav Wikström


0001-org-Grouptags-not-unique-and-can-contain-regexp.patch
Description: Binary data


0002-org-agenda-Filtering-in-the-agenda-on-grouptags.patch
Description: Binary data


0003-org-Nesting-grouptags.patch
Description: Binary data

Re: [O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Nicolas Goaziou]

Hello,

Gustav Wikström gustav.e...@gmail.com writes:

 This time I've made some changes in the code. More specifically in how
 tag groups function and would like them to be included in Orgmode.

Thank you.

 I suppose an FSF-assignment signature is needed before it can be
 included.

Indeed.

 I'll start with that process if this is something the
 community can agree to include. But until then; please take it for a
 ride.

OK. Some comments follow.

 The changes are listed below:

 - Grouptags don't have to be unique on a headline if added with [ ]
   instead of with { }:
   ,
   | #+TAGS: [ group : include1 included2 ]
   `

I'd rather not introduce yet another syntax for group tags. IIUC, the
current one (with curly braces) can be extended. 

Also, I don't get the have to be unique on a headline part.

 - Grouptags can have regular expressions as sub-tags. The regular
   expressions in the group must be marked up within { }. Example use:

   ,
   | #+TAGS: [ Project : {^P@.+} ]
   `

   Searching for the tag Project will now list all tags also including
   regular expression matches for ^P@.+. it is good, for example, if tags
   for a certain project are tagged with a common project-identifier, i.e.
   P@2014_OrgTags.

This seems an interesting addition.

 - Nesting grouptags. Allowing subtags to be defined as groups
   themselves.

   ,
   | #+TAGS: [ Group : SubOne(1) SubTwo ]
   | #+TAGS: [ SubOne : SubOne1 SubOne2 ]
   | #+TAGS: [ SubTwo : SubTwo1 SubTwo2 ]
   `

   Should be seen as a tree of tags:
   - Group
 - SubOne
   - SubOne1
   - SubOne2
 - SubTwo
   - SubTwo1
   - SubTwo2
   Searching for Group should return all tags defined above.

OK.

   A new variable is defined `ORG-GROUP-TAGS-MAX-DEPTH' that is used to
   limit the depth of recursion when expanding tags. It defaults to 2.

I don't think this variable is necessary. However, a check for circular
inclusions would be necessary.


Regards,

-- 
Nicolas Goaziou

[O] [RFC] [PATCH] Changes to Tag groups - allow nesting and regexps

[Gustav Wikström]

Hi!

My name is Gustav and I'm a user of Orgmode since some time (..years)
now. I've made minor contributions to this list before but mostly in
discussions.

This time I've made some changes in the code. More specifically in how
tag groups function and would like them to be included in Orgmode.

I suppose an FSF-assignment signature is needed before it can be
included. I'll start with that process if this is something the
community can agree to include. But until then; please take it for a
ride. I've attached a file which can be used to test the
functionality. There are a few more things to do too; Like updating
the manual and improving the tag-selection UI. If you have the
interest, please look into that ;-). I suspect some might have
comments on the code too. The tag-expansion function, for example,
(`ORG-TAGS-EXPAND') has grown a bit..

The changes are listed below:

- Grouptags don't have to be unique on a headline if added with [ ]
  instead of with { }:
  ,
  | #+TAGS: [ group : include1 included2 ]
  `

- Grouptags can have regular expressions as sub-tags. The regular
  expressions in the group must be marked up within { }. Example use:

  ,
  | #+TAGS: [ Project : {^P@.+} ]
  `

  Searching for the tag Project will now list all tags also including
  regular expression matches for ^P@.+. it is good, for example, if tags
  for a certain project are tagged with a common project-identifier, i.e.
  P@2014_OrgTags.

- Grouptags are not filtered when setting up tags (in
  `ORG--SETUP-PROCESS-TAGS'). This means they can exist multiple times
  in org-tag-alist. Will be usable if nesting of grouptags is ever
  to become reality.

  There is a slightly annoying side-effect when setting tags, in that a
  tag which is both a part of a grouptag and is a grouptag of its own will
  get multiple key-choices in the selection-UI. The whole selection-UI
  could use some refactoring. Especially with the addition of the point
  below.

- Nesting grouptags. Allowing subtags to be defined as groups
  themselves.

  ,
  | #+TAGS: [ Group : SubOne(1) SubTwo ]
  | #+TAGS: [ SubOne : SubOne1 SubOne2 ]
  | #+TAGS: [ SubTwo : SubTwo1 SubTwo2 ]
  `

  Should be seen as a tree of tags:
  - Group
- SubOne
  - SubOne1
  - SubOne2
- SubTwo
  - SubTwo1
  - SubTwo2
  Searching for Group should return all tags defined above.

  A new variable is defined `ORG-GROUP-TAGS-MAX-DEPTH' that is used to
  limit the depth of recursion when expanding tags. It defaults to 2.

- Filtering in the agenda on grouptags should filter also subcategories.
  Exception if filter is applied with a (double) prefix-argument.

  Filtering in the agenda on subcategories should not filter the above
  levels.

  If a grouptag contains a regular expression the regular expression is
  also used as a filter.

- `ORG-AGENDA-REDO' expands the tag-filters when redrawing the agenda.
  It might be counterintuitive if a filter was applied with a double C-u
  argument just before to *not* expand tags in the filter.

- Some bugs relating to grouptags have been fixed.
  - When filtering on tags in the agenda after using a grouptag, it no
longer complains about wrong type.
  - Regular expressions with tag-names inside are not affected by
group-expansion. Example:

,
| #+TAGS: { Tag : Tag1 Tag2 }
| search expression: {Tag.*} now works predictably.
`

I look forward to hearing what you think!

Best regards
Gustav


Testfile.org
Description: Binary data


0001-Grouptags-not-unique-and-can-contain-regular-exp.patch
Description: Binary data


0002-Filtering-in-the-agenda-on-grouptags.patch
Description: Binary data


0003-Nesting-grouptags.patch
Description: Binary data