From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: [RFC] Modified Babel call execution and property deprecation Date: Fri, 17 Jun 2016 00:25:31 +0200 Message-ID: <87r3bwydno.fsf@saiph.selenimh> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDfjK-0001YM-P7 for emacs-orgmode@gnu.org; Thu, 16 Jun 2016 18:25:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bDfjI-0002Bc-Hr for emacs-orgmode@gnu.org; Thu, 16 Jun 2016 18:25:41 -0400 Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:40916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bDfjI-0002BO-8y for emacs-orgmode@gnu.org; Thu, 16 Jun 2016 18:25:40 -0400 Received: from saiph.selenimh (unknown [IPv6:2a03:a0a0:0:4301::b3c]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 606AD172098 for ; Fri, 17 Jun 2016 00:25:38 +0200 (CEST) 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" To: Org Mode List Hello, I just pushed changes about how Babel calls (including inline calls) are evaluated. Basically, they are not treated anymore as an Emacs Lisp variable, but as virtual Babel source blocks, which can then be executed with `org-babel-execute-src-block'. I had to tweak a few tests in the process so I guess it will introduce a few visible changes, in particular in header args as properties. In any case, please let me know if there's something fishy. That leads me to the second point. I think it's high time to remove the deprecated (3 years ago) syntax for header properties, e.g., :PROPERTIES: :tangle: no :END: I re-read discussions about it from a couple of years ago, and, AFAICT, the arguments against it do not hold anymore. So, if you think this syntax is still useful, i.e., it permits things that the current one cannot, please speak up. Regards, -- Nicolas Goaziou 0x80A93738