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
