From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 8F2rBkP9Ul+7fAAA0tVLHw (envelope-from ) for ; Sat, 05 Sep 2020 02:51:47 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id RVWaAkP9Ul/dFQAA1q6Kng (envelope-from ) for ; Sat, 05 Sep 2020 02:51:47 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 629A89403EE for ; Sat, 5 Sep 2020 02:51:46 +0000 (UTC) Received: from localhost ([::1]:44006 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kEOIp-0000LC-ST for larch@yhetil.org; Fri, 04 Sep 2020 22:51:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54092) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kEOIG-0000Kx-9U for emacs-orgmode@gnu.org; Fri, 04 Sep 2020 22:51:08 -0400 Received: from mail-pg1-x536.google.com ([2607:f8b0:4864:20::536]:43932) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kEOIE-0004aU-Dc for emacs-orgmode@gnu.org; Fri, 04 Sep 2020 22:51:07 -0400 Received: by mail-pg1-x536.google.com with SMTP id d19so5231686pgl.10 for ; Fri, 04 Sep 2020 19:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:user-agent:message-id:mime-version; bh=/GTO6QKqM6HT8TpTXIW/OT8M+k2LCQgjZJcY5ZUq5eI=; b=X3YhYmeKOXjWqOWlwzX/GPwMMyaWhtOqdjSzicQYPkNVIs8XSEcxUmh4LmxUVxrPU5 9fV6n8vd4K0dpLepaFAdn1glVA4A9sdDeUJYRicOAxaxtMHIxyjUPdvG7VvAFV/dy5DL esOrl+Q054l1Won5mkG+oE9h4ChiYPRgeS8MRMtEttOhMDlPv8FnF7ovPvU3Op+q5xiU S5D0OCgsx1ZmQpvOsePtMCDyfdjpdagQZQ58yo+nubuYxQmgWv6WGG3C0jCv7DtyPyMl rDg37q4Fxk/MYwwO4PCJAiJHkTuxnmFi0/QoXErXAqI5bUKVgfKeWScxiN6BFODtFMaU mY0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:user-agent :message-id:mime-version; bh=/GTO6QKqM6HT8TpTXIW/OT8M+k2LCQgjZJcY5ZUq5eI=; b=V0oVVIUi7e5kppoWnVezgEk9yRwdDkKnpKiZvxnoZt8A2WTkG94oiHmpA+9EzFuulc sFi7nVPuwBxgavlacwrhvJ2yEUQvQhyGR/kGrYmPtB0Rk6/SAJDFZW3swiQgE5HbNVaX DFTmqoBNb8v7V/NlYyyGrpTh747rl3LJ/64x4eSD9bXjnrwzVkadweNpcw54jfBQNg0g 28zdv3GtotyTy+TJhycCtaHS8EDIcnRrkUV9MzTOJqndnxuzboYQKZl+W1CcqR4R74DF ynHptds56dixxLR+OJX6AXBwa1k3qZxI5xH3V2hwjx4mo+FG7SNzJm6pmumnzeycdwZs dZvg== X-Gm-Message-State: AOAM532IsW09q5EYiUA2/MXdZvNoeixs/T8KZuVQxLAfBEHrzBZOu1Lh lCcehyc3hI3nQnPqq7T49PnAHImrbP4lZQ== X-Google-Smtp-Source: ABdhPJyq7IFXWJlWXyaTnPPGYYSF7/MQc4680MQxBhTknKluUP16L8/8x1R0xWK77IuwTL8hufwKiA== X-Received: by 2002:aa7:9534:: with SMTP id c20mr11401500pfp.157.1599274262441; Fri, 04 Sep 2020 19:51:02 -0700 (PDT) Received: from flare-121 ([2601:601:cb7f:fc70:8a9:39f3:a55:a0eb]) by smtp.gmail.com with ESMTPSA id l9sm7335114pgg.29.2020.09.04.19.51.01 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 04 Sep 2020 19:51:01 -0700 (PDT) From: flare To: emacs-orgmode@gnu.org Subject: [FEATURE REQUEST] No tangle of code blocks within archived subtrees Date: Fri, 04 Sep 2020 18:31:23 -0700 User-agent: mu4e 1.4.5; emacs 26.3 User-agent: mu4e 1.4.5; emacs 26.3 Message-ID: <877dt9ey2c.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2607:f8b0:4864:20::536; envelope-from=gabrielxaviersmith@gmail.com; helo=mail-pg1-x536.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -11 X-Spam_score: -1.2 X-Spam_bar: - X-Spam_report: (-1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=X3YhYmeK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: 1.49 X-TUID: 7Buix9WNCVvs --=-=-= Content-Type: multipart/alternative; boundary="==-=-=" --==-=-= Content-Type: text/html Content-Disposition: inline

Context

I use org-mode to configure many of my machines on my home network
and use Org's tangle capability to have every configuration file be
seated in the correct place.

Feature Request

I wish that whenever I decide that I want to completely abandon an
implementation of something like networking and interface management
in favor of another, that I would be able to save the previous
implementation in an archive sibling subtree without this previous
implementation's files being tangled.

Warrants

I have considered the possibility of implementing this feature in my
own way so as to not inconvenience another. But after considering that
even if I had designed my own wrapper function or used the pre and
post tangle hooks, it would be very difficult for me to have a
reliable way of stopping org-babel-tangle from tangling these
specific blocks within archived subtrees short of "breaking" the
code blocks with the pre hook and repairing them with the post. Even
then it is a question as to how I would reliably determine which
code blocks were within the archived subtree.

Suggestions

Since one of the issues of solving this is the inability to tell
org-babel-tangle to skip code blocks by their "archivedness" but
instead only by the file they are tangling or the language they are
written in, I would suggest allowing the user to have the ability
to configure a "tangle skip tag" or subtree property that causes
org-babel-tangle to skip over blocks within that/those subtree(s).

You may even wish to have an attribute that tells org-babel-tangle
to skip a specific code block (via org directives,
like #+NAME:). This may be more easy to implement but I am no
expert on the org-babel tangling system. With this however it would
be easy to build wrapper functions to disable tangling of code
blocks within entire subtrees, essentially emulating the desired
"archivedness" that I previously suggested.

Summary

This feature request being very centric as to my situation regarding
the archival of code blocks within sister archive subtrees, it may
seem like it would not be worth one's time to implement it. But as I
have stated I see an issue with the configurability of
org-babel-tangle to disregard the tangling of designated blocks and
subtrees. It would benefit babel's current implementation of tangle,
sitting nicely along side the "tangle based off of language" and
"tangle based off of file being tangled" functionalities; also
benefiting org-mode's archival functionality (as code blocks in
these subtrees wouldn't interfere with non-archived code blocks)

Overall, a configurable variable that allows the user to define a
tag, property or a simple org directive that authoritatively dictates
to org-babel-tangle what to and what not to tangle would be a
welcome and fitting addition to org-mode's capabilities.

Regards

Thank you for your time, and of course with all this written out I
still wish to say. Please forgive me if there is already a feature
that solves this problem, I tried my best to dig that little bit
deeper.

Cheers!

Gabriel Smith

--==-=-=-- --=-=-=--