emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: John Kitchin <jkitchin@andrew.cmu.edu>
To: Lawrence Bottorff <borgauf@gmail.com>
Cc: emacs-orgmode Mailinglist <emacs-orgmode@gnu.org>,
	Kaushal Modi <kaushal.modi@gmail.com>
Subject: Re: Ad-hoc, mix-and-match tag hierarchies?
Date: Sat, 03 Feb 2018 19:18:37 -0800	[thread overview]
Message-ID: <m2lgg9fnn6.fsf@andrew.cmu.edu> (raw)
In-Reply-To: <CAFAhFSUPxONW7j51qOXhi814GNnjsJgnWCj-EcoLFQKQVDk7TA@mail.gmail.com>

I don't think you are missing anything. Your first example leverages inheritance (and you can turn that off if you don't want it), and your second example doesn't.

In any case, the order of the tags is irrelevant. To me the real question is what do you want to use them for?

I use them in agenda queries, and there the order is not important. That
is a nice feature, since you don't have to know the hierarchy, and can
query emacs+lisp or lisp+emacs for example and get the same things.
Suppose you have the headers at the end of this email.

These:

(org-tags-view nil "emacs+lisp")
(org-tags-view nil "lisp+emacs")

 both show in the agenda (these are in a file called 2018-02-03.org)

  2018-02-03: header 1.1.1                                                     :emacs:orgmode::lisp:
  2018-02-03: header b                                                          :emacs:orgmode:lisp:
  2018-02-03: header B                                                          :lisp:emacs:orgmode:

Note that header 1.1.1 has all the tags from inheritance, and the other
two have all the tags in different orders. You can use a query like
"emacs-orgmode" to get headlines tagged emacs and not tagged orgmode.







* header 1            :emacs:

** header 1.1       :orgmode:

*** header 1.1.1   :lisp:
stuff about Emacs' org-mode's lisp code

* header a                                                            :emacs:
stuff about Emacs
* header b  :emacs:orgmode:lisp:
stuff about Emacs' org-mode's lisp code
* header B :lisp:emacs:orgmode:
The tag order is not important

* header c                                                             :lisp:
stuff about just Common Lisp
* header d                                                    :emacs:orgmode:
stuff about Emacs' org-mode
* header e                                                            :emacs:
more stuff about Emacs


Lawrence Bottorff writes:

> So a left-to-right listing of (colon-separated) tags after the heading
> cannot imply a higher-to-lower hierarchical order? So there is no hierarchy
> unless you create it, e.g.,
>
> (setq org-tag-alist '((:startgrouptag)
>                        ("GTD")
>                       (:grouptags)
>                       ("Control")
>                       ("Persp") ...
>
> -- is what I'm hearing.
>
> What I meant to do is to be able to use tags alone or together. And when
> used together, to somehow imply hierarchy. So if I have
>
> * header 1            :emacs:
>
> ** header 1.1       :orgmode:
>
> *** header 1.1.1   :lisp:
> stuff about Emacs' org-mode's lisp code
>
> this implies subject hierarchy simply from the headers' hierarchy. However
> this
>
> * header 1   :emacs:
> stuff about Emacs
> * header 2  :emacs:orgmode:lisp
> stuff about Emacs' org-mode's lisp code
> * header 3 :lisp:
> stuff about just Common Lisp
> * header 4 :emacs:orgmode:
> stuff about Emacs' org-mode
> * header 5  :emacs:
> more stuff about Emacs
>
> is all peers header-wise, while the tags (if using left-to-right listing to
> mean higher to lower in hierarchy) tell us the depth level of
> specialization of a topic. The first set of headers is relying (clumsily)
> on the header level to indicate depth of specialization, which is not
> always realistic. If I wanted, ad-hoc, to indicate levels of some hierarchy
> with tags, that is, not be forced to create empty superior headers, it
> seems  there's no prescribed way to do this. And creating tag hierarchies
> by hand, i.e., (setq org-tag-alist '((:startgrouptag)..., makes me play the
> combinatorics game of imagining all different possible hierarchy
> combinations. Or am I missing something?
>
> On Thu, Feb 1, 2018 at 10:36 AM, Kaushal Modi <kaushal.modi@gmail.com>
> wrote:
>
>> On Thu, Feb 1, 2018 at 10:30 AM John Kitchin <jkitchin@andrew.cmu.edu>
>> wrote:
>>
>>> I was not aware of any implied hierarchy with tags. The order is not
>>> important as far as I know, and what you describe as mix-and-match seems
>>> ok. There is an idea of inheritance, e.g. sub-headings can inherit tags
>>> from higher headings.
>>>
>>
>> Same here.
>>
>>
>>> I am not sure about the org-mode tag.
>>>
>>
>> "-" is an invalid tag character.. the tag can be "org_mode", but not
>> "org-mode". Last time I tried using hyphen, I remember that the tag
>> auto-alignment would stop working (C-u C-c C-q) and also the tag face won't
>> be applied.
>>
>> @Lawrence:
>>
>> You can have tag inheritance this way:
>>
>> * Emacs :emacs:
>> Emacs stuff
>> ** Lisp :lisp:
>> Emacs lisp stuff here
>> *** Org :org_mode:
>> Emacs + Lisp + Org mode stuff
>> ** Org :org_mode:
>> Emacs + Org mode stuff (but not lisp)
>> --
>>
>> Kaushal Modi
>>


--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

      reply	other threads:[~2018-02-04  3:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-01 15:07 Ad-hoc, mix-and-match tag hierarchies? Lawrence Bottorff
2018-02-01 15:28 ` John Kitchin
2018-02-01 15:36   ` Kaushal Modi
2018-02-01 19:45     ` Lawrence Bottorff
2018-02-04  3:18       ` John Kitchin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2lgg9fnn6.fsf@andrew.cmu.edu \
    --to=jkitchin@andrew.cmu.edu \
    --cc=borgauf@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=kaushal.modi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).