From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Edgington Subject: Re: proposal to have ignoreheading tags/properties Date: Mon, 16 Jun 2014 12:19:08 +0000 (UTC) Message-ID: References: <87tx7qxahl.fsf@gmail.com> <87ppie2c2h.fsf@gmail.com> <871tutx4t4.fsf@gmail.com> <87mwdfzmox.fsf@nicolasgoaziou.fr> <87zjhdk63p.fsf@gmail.com> <87oaxtmg36.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwVsn-0007Iz-0Q for emacs-orgmode@gnu.org; Mon, 16 Jun 2014 08:19:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WwVsg-0004Qs-UM for emacs-orgmode@gnu.org; Mon, 16 Jun 2014 08:19:28 -0400 Received: from plane.gmane.org ([80.91.229.3]:39919) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwVsg-0004Qh-N0 for emacs-orgmode@gnu.org; Mon, 16 Jun 2014 08:19:22 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WwVse-0000ca-S1 for emacs-orgmode@gnu.org; Mon, 16 Jun 2014 14:19:21 +0200 Received: from c-71-238-75-211.hsd1.mi.comcast.net ([71.238.75.211]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Jun 2014 14:19:20 +0200 Received: from edgimar by c-71-238-75-211.hsd1.mi.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 16 Jun 2014 14:19:20 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Nicolas Goaziou nicolasgoaziou.fr> writes: > Moreover, that task is highly specific; I'm not convinced we should have > a dedicated keyword for each of them. I'd rather have a simple solution > for selective export problems, even if, as a generic solution, it may > look clumsier. Hi Nicolas, I agree that the nested use of :export: and :noexport: symmetric is a good feature to implement. I think the main point of contention that I and others may have is that even if the :ignoreexport: (or whatever you wish to call it) tag is "highly specific" w.r.t. the variety of export/noexport arrangements one can have, it is also highly useful. While implementing a specific tag for this task may not be wise to implement at this time, there should be *some* way that an org-mode user can avoid being required to manually add export tags to every child of a noexport node in order to achieve this "summary node" functionality. In order to make it possible to add a non-exported summary-node (i.e. a node which we might have marked as :ignoreexport:) at any location in the tree without needing to add N more tags for all of the children, one would need to somehow "by default" have :export: tags implicit on all nodes, unless a :noexport: tag was on a node which would override the behavior of the :export: tag. Maybe there needs to be a way to decide whether a specific tag (i.e. on a specific headline) will be applied recursively or not -- e.g. if the tag has a "*" suffix appended to it, then it is applied to all descendants recursively, but otherwise it applies only to the single headline it is on. Ultimately I see the problem of having to tag all of the children as stemming from this default behavior of tags being recursive. Having control of their "recursivitiy" would alleviate the problem. Regards, Mark