emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Tina Russell <tinakellyrussell@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Mutually-exclusive Org tags still inherit each other
Date: Mon, 04 Mar 2019 10:48:19 +0100	[thread overview]
Message-ID: <87zhqbc6n0.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <CAJBHbT54wVNCbaEt2twd_4SMLXMqknoj7yYAU4-fhicmpJ2V9w@mail.gmail.com> (Tina Russell's message of "Fri, 1 Mar 2019 13:47:44 -0800")

Hello,

Tina Russell <tinakellyrussell@gmail.com> writes:

> Well, I think it’s unreasonable to ask users to reinforce manually and
> continuously something they’ve already specified in their settings.
> Besides, my example was intentionally trivial—imagine managing a large
> tree and having to remember which tags are mutually exclusive to what,
> all the time.
>
> But, no matter! I have created a patch! It works great, even for edge
> cases like when an entry has two tags that are set as mutually
> exclusive to each other.

Thank you for the patch.

Unfortunately, I think we are miscommunicating, because we are thinking
at different levels of abstraction. Le me clarify this.

Org syntax supports colons-wrapped cookies at the end of a headline,
called tags. That's about it. Of course, you can extend those cookies to
support, e.g., inheritance, groups, mutual exclusion, and whatnot. But
at the lowest level, there are only cookies at the end of a headline.

The function `org-get-tags' was implemented to get those, possibly with
inheritance. Most, if not all, of its callers in the code base do not
care about groups, or mutual exclusion. Also, most, if not all, callers
care about internal tags. Not that some internal tags are automatically
inherited, hence support for this mechanism in `org-get-tags'.

You apparently have a need for user-defined tags, with all bells and
whistles. However, IIUC, you don't really need to list them, but
ultimately do a tag search on them. 

There are advanced functions for tag searches: `org-make-tags-matcher'
and `org-scan-tags'. My point is that you should first check if they
already do what you want, and patch them otherwise, instead of changing
`org-get-tags', which has a clear scope.

WDYT?

Regards,

-- 
Nicolas Goaziou

      reply	other threads:[~2019-03-04  9:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-08  0:42 Mutually-exclusive Org tags still inherit each other Tina Russell
2019-02-09 18:03 ` Nicolas Goaziou
2019-03-01 21:47   ` Tina Russell
2019-03-04  9:48     ` Nicolas Goaziou [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=87zhqbc6n0.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=emacs-orgmode@gnu.org \
    --cc=tinakellyrussell@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).