On 10/16/10 4:09 PM, Carsten Dominik wrote:
On Oct 16, 2010, at 9:26 PM, Robert Horn wrote:
On 10/16/2010 01:32 AM, Carsten Dominik wrote:
On Oct 15, 2010, at 4:43 PM, Ilya Shlyakhter wrote:
Karl Maihofer <ignoramus <at> gmx.de> writes:
Besides that I have tags in other contexts, e.g. GTD-related
tags etc.
So it would be very useful to be able to group the tags as it is
possible for agenda commands.
I think that a way to define logical groups of tags (or even a
hierarchy of tags
-- say with a subtree of tag names?) would be a very useful
addition.
I can see that this could be useful - but the code is
not in any way prepared to do this, so this would be pretty hard
to implement.
Is it worth exploring use of the properties drawer? The tags in
org are
a fairly simple and thus limited structure. The properties drawer
can
have a lot more structure with a more controlled environment.
I don't think I understand what you mean here. How would that help?
- Carsten
My first thought was just to deal with visual clutter and parsing
headaches. Encoding standards like IDv3 have a large list of tags and
tags with values that are encoded and hidden in MP3 files. The display
is controlled by application. This is very much like the drawer
behavior in org. So putting tags into drawers would deal with the
clutter associated with having a great many tags on one item.
The next level would be to have org aware of the tag structure. This
would mean having a vocabulary description that describes the tags.
The vocabulary can be described as:
Top level: Context, e.g., GTD
Level 1: TagA
Level 2: TagB, a kind of TagA
Level 3: TagC, a kind of TagB
Level 1: TagD
etc
Usually Tags are unique with in a context, but might collide between
contexts. So I might find the tag "TASK" used in different contexts.
Multiple tags can occur within a context, so something might have TagA
and TagD, and the presence of a lower level tag implies the higher
level
tags. So TagC would imply TagB and TagA in the example above.
This is a simplification of full ontological structures that can be
expressed in a language like OWL, but it is one that people can grasp
and use easily. It meets most needs. The music and photographic
standards and their easy usage indicates this.
The vocabulary description could easily be done with some lisp
customization, the way it is done for task states, or it could be in
an
org file. Both ways have their advantages.
For each tag you can have a list of pairs of context+tag to keep tags
unique. Appending these as text to each line introduces a lot of
visual
clutter and parsing headaches. I would put these into drawers to
reduce
the visual clutter and manage duplication. For the tag descriptions I
would have another location that has the full structure of tags, so
that
a friendly display selection could be used that reflects the
hierarchy.
A tag assignment similar to the IDO selection of levels within an org
hierarchy would make sense. Perhaps an org structure would make sense
for the vocabulary.
A simpler tag that means "look in the tags drawer" would keep the text
file readable and let the agenda processing deal with extracting and
displaying. Non agenda views of the org file would just have the "look
in tags drawer" tag. The viewing options would need to recognize
this to
control how the drawer tags are displayed.
R Horn
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-orgmode