emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] "Tag hierarchy" idea


From: Christian Moe
Subject: Re: [O] "Tag hierarchy" idea
Date: Tue, 22 Mar 2011 09:27:38 +0100
User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9

Hi,

There was some discussion of tag hierarchies in this thread:

http://thread.gmane.org/gmane.emacs.orgmode/31882

It was largely inconclusive, except that it would be hard to implement. Noone took the ball and ran with it, but then noone came up with a strong use case or specification, either. Anyway, I recommend a look at that thread before continuing it here.

Yours,
Christian

On 3/22/11 12:09 AM, John Tait wrote:
Hi all

This is my first post. First, I'd like to thank all the org-mode
developers for a great tool.

I'm a technical editor. I am facinated by the pros and cons of
structured documents with regard to their ease of use and power. I
think that they are probably far too restrictive and cumbersome
(looking at you, DITA) for the average technical document.
Nevertheless, the idea of modular documents is an appealing one to me.
I like conditional text features (e.g. in LyX).

In org-mode, I really really love selective export (include/exclude
tags) and using #+INCLUDE: for including other files. This gives me
enormous flexibility, with zero DITA pain.

May I propose an additional feature? I haven't seen anything like it
published anywhere, though maybe I am using the incorrect search
terms. (I am getting enormous vertigo and time-travel sickness reading
up on Lisp, XML, DITA, etc.)

It's a pretty basic idea, but I hope you can take a moment to weigh up
its potential.

We could assign tags to hierarchies of other tags.


#+TAG-NEST: (colour(red green blue))
#+TAG-NEST: (type(colour size))
#+TAG-NEST: (car(type price))

or maybe like this. I'd leave it up to someone with actual programming
experience and a logical mind (my productive programming was PASCAL in
1991) to suggest a rigorous system that makes sense.

#+TAG-NEST: colour > red:green:blue
#+TAG-NEST: type > colour:size
#+TAG-NEST: car > type:price

The point of this would be that selecting, say, "colour" as a tag
would bring along "red", "green", and "blue" along with it. The tag
"type" would bring "colour", "red", "green", "blue" and "size" with it.

The power of this would be that hierarchies could be adjusted and
manipulated as necessary.

Since there is no one definitive way to tag real world objects and
ideas into nice nested boxes (thanks, AI research), we could adjust
any tag hierarchies to suit experience and changing priorities. Even
hierarchies could just be thrown away without affecting existing tags
too much, since tagged headings could just be selected/excluded as usual.

This way, we can use concept hierarchies as the disposable
conveniences that they are, without getting locked into them. Looking
at stuff like XSLT transformation for XML, that'd be worth avoiding.

Maybe there is some logical lispy reason why this couldn't work, but I
hope this is worthy of your consideration.

John

------

While I am here (sorry), I couldn't get #+FILETAGS: to work in
org-version 7.4.

For example, if I export a file (to html) File1.org  with
"#+EXPORT_EXCLUDE_TAGS: john", and then I include File2.org, I can see
File2.org included as part the export of File1 as expected. If I then
set "#+FILETAGS: :john:" in File2, I'd expect File2 to now be
excluded, but it still appears. If I then tag a File2 heading as say
"* Heading :john:", then it won't appear in the File1 export, as
expected. Am I missing something?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]