From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id QMrfH0EBr197JgAA0tVLHw (envelope-from ) for ; Fri, 13 Nov 2020 21:57:21 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 2AbOG0EBr1/1YQAAbx9fmQ (envelope-from ) for ; Fri, 13 Nov 2020 21:57:21 +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 15AFD9401BF for ; Fri, 13 Nov 2020 21:57:21 +0000 (UTC) Received: from localhost ([::1]:40134 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdh4I-0004WV-KF for larch@yhetil.org; Fri, 13 Nov 2020 16:57:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37360) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdh3t-0004WA-Mo for emacs-orgmode@gnu.org; Fri, 13 Nov 2020 16:56:53 -0500 Received: from grinta.net ([109.74.203.128]:53774) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdh3r-0001ui-C6 for emacs-orgmode@gnu.org; Fri, 13 Nov 2020 16:56:53 -0500 Received: from black.local (p4fe71be7.dip0.t-ipconnect.de [79.231.27.231]) (Authenticated sender: daniele) by grinta.net (Postfix) with ESMTPSA id 3F00FEE119 for ; Fri, 13 Nov 2020 21:56:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=grinta.net; s=2020; t=1605304609; bh=ibX83Dj3GQTQ7ALsrKMXvoOd9h/hiddmIc+IedB64mE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gxuUTaQGdekxx4OvyzW8kURYlprz+00Jb9ZG6mvasUo90g1WbtYQG3O0uO9wyvkc/ OQRB24+stDNeGEgUw9HYyh28riUaO5GVq5fU6TPyHePcnxH573Lwt6fZB+iICVvu2c 65dvAYttjtasrfZXppkzAbNqikiXe6V0WpgG/N8WGC406qRby97W3ePUXLN6IMjZ8H TnGjkISG4fleZ8JXmGlUql3ewDjcSTMclKIn/Ykj7AT4ZUuxMN/s7nhZZDHHMh8WvE 9pViB/hz1cUBrCrAWhV49AoWdOMMgNvJm7fAQM4Ffg56Bo6NgA5fXCAI0BeEZ2hCjs mTWqoA21wWFWA== Subject: Re: How is org-sbe supposed to work? To: emacs-orgmode@gnu.org References: <7de3bd69-4604-302a-b6d4-4e190f23bdb8@grinta.net> From: Daniele Nicolodi Message-ID: Date: Fri, 13 Nov 2020 22:56:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <7de3bd69-4604-302a-b6d4-4e190f23bdb8@grinta.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=109.74.203.128; envelope-from=daniele@grinta.net; helo=grinta.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/13 16:56:49 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, NICE_REPLY_A=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01 autolearn=ham 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: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=grinta.net header.s=2020 header.b=gxuUTaQG; dmarc=none; 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: 0.99 X-TUID: Qmi6bfz9VFke On 13/11/2020 15:39, Daniele Nicolodi wrote: > How are variables passed to the code block supposed to be handled? The > macro docstring does not mention anything particular, thus I would > imagine they are handled just like in any other lisp code. However, this > does not seem to be the case. After some more testing and starring at the code some more, it seems that the odd behavior comes from the attempt of org-sbe to be clever and do not require to use the N flag in the org table formula definition to parse numbers as such, maybe. Anyway, I came up with an alternative macro that does what I would expect org-sbe to do, acting as a transparent interface to execute org code blocks, without surprises: (defun org-sbx1 (name header args) (let* ((args (mapconcat (lambda (x) (format "%s=%S" (symbol-name (car x)) (cadr x))) args ", ")) (ctx (list 'babel-call (list :call name :name name :inside-header header :arguments args :end-header ":results silent"))) (info (org-babel-lob-get-info ctx))) (when info (org-babel-execute-src-block nil info)))) (defmacro org-sbx (name &rest args) (let* ((header (if (stringp (car args)) (car args) nil)) (args (if (stringp (car args)) (cdr args) args))) (unless (stringp name) (setq name (symbol-name name))) (let ((result (org-sbx1 name header args))) (org-trim (if (stringp result) result (format "%S" result)))))) which I find significantly simpler than the implementation of org-sbe. It works emulating what a #+call: directive does constructing by hand the parsed version returned by org-element-parse. Demo: #+name: sum #+begin_src elisp :var x='(2 3) (apply '+ x) #+end_src #+name: concat #+begin_src elisp :var x='() (apply 'concat x) #+end_src | 1 | 2 | 3 | 4 | 5 | 15 | 15 | | a | b | c | d | e | abcde | abcde | #+TBLFM: @1$6='(org-sbx sum (x '($1..$5)));N #+TBLFM: @1$7='(apply '+ '($1..$5));N #+TBLFM: @2$6='(org-sbx concat (x '($1..$5))) #+TBLFM: @2$7='(apply 'concat '($1..$5)) The only problem I have with it is that the point jumps around during evaluation and that while the macro is evaluated the formula definition line is duplicated. I haven't yet investigated why (however the same happens with org-sbe). It may be that it is not too difficult to avoid having to convert the arguments to a string representation and back, but this would require digging a bit deeper into ob-core.el. Cheers, Dan