From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id MKnRNmwKC2SmBwAASxT56A (envelope-from ) for ; Fri, 10 Mar 2023 11:46:04 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id EI6KNmwKC2QkEgAAauVa8A (envelope-from ) for ; Fri, 10 Mar 2023 11:46:04 +0100 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 91A64BF55 for ; Fri, 10 Mar 2023 11:46:04 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paaFf-0004S4-02; Fri, 10 Mar 2023 05:45:31 -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 1paaFb-0004Rc-Cz for emacs-orgmode@gnu.org; Fri, 10 Mar 2023 05:45:28 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1paaFZ-0007fH-1a for emacs-orgmode@gnu.org; Fri, 10 Mar 2023 05:45:26 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 2F54F24033C for ; Fri, 10 Mar 2023 11:45:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1678445123; bh=LbdIQSdzeXV2umaXZJPUCr0xcCEHH8VDFXaqJ0oycw0=; h=Date:Subject:To:Cc:From:From; b=f5uUM2D8bwgXATaGnbDP4a7fDIND/EtS/+iZWHmBGgff4iizUgo1qFLSBsCf7zpb3 KJ2Z0WOhIToUUJFoS8/VV+u5RhXsHiKTGhgGAHFkuq1Zk01BL90djasCYfpTZO1oTk KbeDZSKC72O4BIMCVVwc0vzPI6NXWqCOOAl7N7rEw7t185iNY7zXTPOwMlPk0lVNLM FZhvW6pkqI1ykzC6CWD6MM8RazjF9HZwStTMTG8o3RrJhR1XINt+Yvmc9iHiZ9NgU/ Zmxv3CWk7D7qolc0H1v8dRscB2MMwOTMiS3g98U6l3zoU5O2BhztF66yI41mS63ePk Xo15/tZi/qquQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PY2kn5tQHz9rxM; Fri, 10 Mar 2023 11:45:21 +0100 (CET) Content-Type: multipart/alternative; boundary="------------cJViAypz8PpiUsS1hKx7SBUW" Message-ID: Date: Fri, 10 Mar 2023 10:45:21 +0000 MIME-Version: 1.0 Subject: Re: org-babel guile source block bug in handling multiple values Content-Language: en-US To: Ihor Radchenko Cc: Bruno Barbier , emacs-orgmode@gnu.org, Daniel Kraus , Bastien References: <9eab60bc-9b82-e037-d63b-3d879573ae32@posteo.de> <87v8jceihi.fsf@localhost> <7fc63848-d6d3-80e0-ae78-00967990813d@posteo.de> <64079614.170a0220.5a0d3.0a23@mx.google.com> <97ee254e-72d2-2bdf-e026-78bde076f1f9@posteo.de> <6408e424.5d0a0220.8862a.2a62@mx.google.com> <87pm9ioyrg.fsf@localhost> From: Zelphir Kaltstahl In-Reply-To: <87pm9ioyrg.fsf@localhost> Received-SPF: pass client-ip=185.67.36.65; envelope-from=zelphirkaltstahl@posteo.de; helo=mout01.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1678445164; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=vJ3alA/rqFrLOFGwS1SpTFSj+ECfF+8jxf7A2BM/tHQ=; b=S0GDWY/rRQxt6nqoHfZlzRTBywcdeqRdHx21GVY5c+RyFXjRD+oUvFZJSpkbokTvg1nY3D bs+7ZsH5NM2FocMtHRoyDzE/m8WVHubndglAYfQ0iP9Nqr2pJ9XZ2z/j9EiSky9FQ3HsPX vF5ixAAzWqsWYw0K6W8wxmRzSd+mpKeUbZbJOiXxfsWnyuySu7kpbI98IoR5h6Ertry426 Ih+jL2+2+Es3bJ1MuwWWqmrJSzCAXfrWU4YOiuuuJh7VQiMsvDbVp9TVZobRkptzlW1u5H MRipkNYeO7T6VRj5HC0UpRaBlDpzU+RThLANUbDJBt2BeUSc3R7edFkQZnEl5w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.de header.s=2017 header.b=f5uUM2D8; 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.de ARC-Seal: i=1; s=key1; d=yhetil.org; t=1678445164; a=rsa-sha256; cv=none; b=ntK/XbAJaaEf9b0JoJlhT4dEqrVilwdx16YKOqRMpxQ9YapX+YQkNdTRWSF9wO+KKNPyoV LMlc3X1KMWxVZPg0HppjlotViPx2eCyBxBtA5E9CYUU3D4SZtg+nNRLIOtWfA/jkx0hyXi Op5F4GOs09Yx9j0xiwkarFLA+CRFlKTpmRtBhG+4rupKm8a3uuVXPiTEZOsArKDlTzof9L A0DiIM4aIjvJK/jS6XQDEwDJq+BATO+6hYDhDNfpskNyeWcuIHU3aoAcd2dWDzyb9t/9go v+Z+UwgYc/XycC2l8GhnDwjvdqqAE22sWOHWMrCDF15O1YvcO7+vULHU7N0Hbw== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.de header.s=2017 header.b=f5uUM2D8; 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.de X-Migadu-Spam-Score: -6.27 X-Spam-Score: -6.27 X-Migadu-Queue-Id: 91A64BF55 X-Migadu-Scanner: scn1.migadu.com X-TUID: UUU8/si6ZKGa This is a multi-part message in MIME format. --------------cJViAypz8PpiUsS1hKx7SBUW Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/9/23 14:11, Ihor Radchenko wrote: > Zelphir Kaltstahl writes: > >> OK, to wrap up (ha!), I want to ask: >> >> (q1) What is a rationale, if any, behind the let-wrapping? > It makes sense in ob-emacs-lisp to not litter global Emacs state. > In other ob-* lisp backends, I am not sure. > I am CCing Daniel, the maintainer of ob-clojure (we have no active > maintainer for ob-scheme now). Maybe, Daniel has some useful insight. > >> (q2) Any chances of that changing to (define ...)? > This sounds reasonable. > >> (q3) How could I change my org-mode's code to not  let-wrap, and instead use >> (define ...)? > See `org-babel-expand-body:scheme'. You can re-define it for a quick > temporary fix. Thanks for the hint! Here is my fix for my init.el: ~~~~START~~~~ ;; Redefine/override org-babel-expand-body:scheme to avoid ;; let-wrapping with :var header args in source blocks. (defun xiaolong/org-babel-format-vars (vars) "Format :var header arguments given as VARS." (mapconcat (lambda (var) (format "(define %s %S)" (car var) (cdr var))) vars "\n")) (eval-after-load "org" '(defun org-babel-expand-body:scheme (body params) "Expand BODY according to PARAMS, return the expanded body." (let ((vars (org-babel--get-vars params)) (prepends (cdr (assq :prologue params))) (postpends (cdr (assq :epilogue params)))) (concat (and prepends (concat prepends "\n")) (if (null vars) body (concat (xiaolong/org-babel-format-vars vars) body)) (and postpends (concat "\n" postpends)))))) ~~~~~END~~~~~ That was simpler than I expected and the first time I overrode anything of org-mode =) Regards, Zelphir -- repositories:https://notabug.org/ZelphirKaltstahl --------------cJViAypz8PpiUsS1hKx7SBUW Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 3/9/23 14:11, Ihor Radchenko wrote:
Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:


OK, to wrap up (ha!), I want to ask:

(q1) What is a rationale, if any, behind the let-wrapping?

It makes sense in ob-emacs-lisp to not litter global Emacs state.
In other ob-* lisp backends, I am not sure.
I am CCing Daniel, the maintainer of ob-clojure (we have no active
maintainer for ob-scheme now). Maybe, Daniel has some useful insight.


(q2) Any chances of that changing to (define ...)?

This sounds reasonable.


(q3) How could I change my org-mode's code to not  let-wrap, and instead use 
(define ...)?

See `org-babel-expand-body:scheme'. You can re-define it for a quick
temporary fix.

Thanks for the hint!

Here is my fix for my init.el:

~~~~START~~~~
;; Redefine/override org-babel-expand-body:scheme to avoid
;; let-wrapping with :var header args in source blocks.

(defun xiaolong/org-babel-format-vars (vars)
  "Format :var header arguments given as VARS."
  (mapconcat (lambda (var)
               (format "(define %s %S)" (car var) (cdr var)))
             vars
             "\n"))

(eval-after-load "org"
  '(defun org-babel-expand-body:scheme (body params)
     "Expand BODY according to PARAMS, return the expanded body."
     (let ((vars (org-babel--get-vars params))
           (prepends (cdr (assq :prologue params)))
           (postpends (cdr (assq :epilogue params))))
       (concat (and prepends (concat prepends "\n"))
               (if (null vars)
                   body
                 (concat (xiaolong/org-babel-format-vars vars) body))
               (and postpends (concat "\n" postpends))))))
~~~~~END~~~~~

That was simpler than I expected and the first time I overrode anything of org-mode =)

Regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl
--------------cJViAypz8PpiUsS1hKx7SBUW--