From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id iNSHNCMmaGdpVgEA62LTzQ:P1 (envelope-from ) for ; Sun, 22 Dec 2024 14:45:56 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id iNSHNCMmaGdpVgEA62LTzQ (envelope-from ) for ; Sun, 22 Dec 2024 15:45:55 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=GKlcslog; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1734878755; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=TvdNtEGsNsHnFr3h8V3iNX9zYrHoyRKbqd19SHdpU14=; b=tVX0/OEDfjTcSuxf08lGwkI1tW471FOs3qW5GsHnPHvlk0+NBGYbxxQuWEnNO1VatlSVk5 I5z/5cObIjdeHJFQTpDZKmbULCU6ukQ1F0Jlv9NPlFXojyzf3qx8wGFfkphWWPgNHzKK7o rwxOJcWna/mEYwf5+Z3uSBUDgM/PFV9j+Cq/+3mwaFEGWGRof0D3EYk9DNU8zZBfipF6DU nmasUliGaXweRx58pi0e07KvgP008damGG50+g/XdJitWpnRoOwQ74MZ0wQXUzM1E/0A/S lO5aoR4BxZ1ABTV7RH/i3yUjQ7K6UUcmQQtPR00mPsP+6detJmyY082Rhp1zXQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=GKlcslog; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1734878755; a=rsa-sha256; cv=none; b=CyJ/0F3RKZOKRNOasbMQxr/8pdovG5Rh5IQd0NKTA1hTVmoabM+W1HASwI3ixZrug7Frpl ebFCOavZgH5j5g24AikoAptkx2yg6HVRLz9mx2gUQ4u6VBSE4A0HD1r9RSlJwZPlTJy/SU 9FaHsxMV923u+wjPDty9k/irc8SsvEw+i4ulkhQex56E+cArZU1nhJOa/4eGAyKYCO742o Eo9brIHrhr1GjmoQEa01/Y6/uRmKtEGBDLQ5in19qASI0PSUmTn9QEIT+u2XqgPnasrnCM HctNPH4XHJ7rjCap5kXz4x1v9k74xCFlENcvePVCLRQw5bUISP4dgMQu/Ir7NA== 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 688707EC1E for ; Sun, 22 Dec 2024 15:45:55 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPLBU-0007BU-52; Sun, 22 Dec 2024 07:35:48 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPLBO-00075x-5i for emacs-orgmode@gnu.org; Sun, 22 Dec 2024 07:35:42 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPLBK-0004mB-GV for emacs-orgmode@gnu.org; Sun, 22 Dec 2024 07:35:40 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 64E47240101 for ; Sun, 22 Dec 2024 13:35:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1734870935; bh=NVXGNBBkzj4CneAyk+G6oMwRbtpsYMKKRCFfHMpiDSw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=GKlcslogl4Rk8k+6vwiJzF3bkZwC4B7ANgzFotcZsXe/rPMuE1mY4zgynpQT93NF6 1dm3IWbULi1oePmkxnFTIh7ktBtFuMLbBJMoK812GsNpYzwRqisz0O63LWamUVpZUN W6K2Nn/+J8s0g8kewVMEPOAZCvgA1hbY6kddO68tJ9mKQZRl+3w+77URP6iUlfPkik GbhxND4cngRl99V3ZosNx3k+IldvkD70BIxYD4T7Js206CY0xDrkYnpqkS8DDe7IJx 4j8qCBFuZXKWne08a5SEN+mc9Ez/MdiZcwR/ExOxhVthXjK3ZUQla1cHAT+oBSYwxi RMHRQYBiujEJQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YGLGZ5Ywnz6tvs; Sun, 22 Dec 2024 13:35:34 +0100 (CET) From: Ihor Radchenko To: Thibaut Meyer Cc: emacs-orgmode@gnu.org Subject: Re: [BUG] Inconsistent org-babel tangle behaviour In-Reply-To: <87v7vpgxaa.fsf@thibaut.dev> References: <87v7vpgxaa.fsf@thibaut.dev> Date: Sun, 22 Dec 2024 12:37:06 +0000 Message-ID: <87ikrb99n1.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx11.migadu.com X-Migadu-Spam-Score: -5.99 X-Spam-Score: -5.99 X-Migadu-Queue-Id: 688707EC1E X-TUID: gQQN5aNBqlOM Thibaut Meyer via "General discussions about Org-mode." writes: > setting a property in an org file like > > '#+PROPERTY: header-args :tangle "file.ext"' > > with a source block of the form: > (note no language is specified for the block) > > #+begin_src > <1: this block won't get tangled> > #+end_src > > won't tangle the block Currently, source blocks without language are never tangled. > what's weirder is, just adding to a block the ":tangle" header without > or with any value, even with the value no, makes the tangling process > respect the header-args property value and thus the block will tangle > successfully. > (note no language is specified for the block) > #+begin_src :tangle no > <3: this block will get tangled!!> > #+end_src Here, a language is actually specified. The language is ":tangle" (there is nothing stopping anyone from creating a language name starting from colon). > The behaviour doesn't seem super consistent. Ideally, I think having a > source block like the first one gettin tangled would be good, and having > the third one not tangle would be better as well. Src block without language could indeed be tangled in your case. However, if the :tangle value is set to something like "yes", there is no way or can deduce the tangle file name. Note that M-x org-lint warns about src blocks without language. While src blocks without language are allowed syntactically, many Org features will not work with such blocks. Usually, you can simply use "conf" or "text" language name as a placeholder. I guess we can support the scenario you described, but I am not sure if we should. > The documentation states: > [Working with source code > Structure of Code Blocks] > "When =E2=80=98=E2=80=99 identifier is omitted, the block also = cannot have > =E2=80=98=E2=80=99 and =E2=80=98
=E2=80=99." > > but, to my knowledge, there is no mention regarding the fact that the > headers assigned through the "header-args" property should not be > applied if a block has no language identifier. That part of the manual can be improved. Maybe something like below. When =3D=3D identifier is omitted, the block also should not have =3D=3D and =3D
=3D. Otherwise, the first switch/argument will be treated as =3D=3D. Let me know if it clarifies things. --=20 Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at