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
