[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 : address@hidden ]
  `----

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

- 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