From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 0N4lIV1M92UjAQEAqHPOHw:P1 (envelope-from ) for ; Sun, 17 Mar 2024 21:02:37 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 0N4lIV1M92UjAQEAqHPOHw (envelope-from ) for ; Sun, 17 Mar 2024 21:02:37 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=excalamus.com header.s=zmail header.b=cYC5PLz1; 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=none; arc=pass ("zohomail.com:s=zohoarc:i=1") ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1710705757; 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=ZNOA9mzKDHiyaM7WKj14u4jkJz6IA3WwZAT6PINx6j8=; b=Ct3rgsvFqcQY/V/ceSH56gX/kXWQ5fBxVQukF9Taxec8RF9/QYmc9B8nxzGMc13E2i36jo EEHoE72RIqHChst9Vm6CjKqvwilbavi8lwB6DM3PGYoEm97zBRYy9MhVQrkR5LaVEW2Ltf Rdzl0qR2qshaCcmKCN4lR8fF7ta7fFW2Xi0GqEGIG7ohXkObn1IG0Q0KBwNOdbfoMUrQjO UAtmfgop/4HdwyIJHfWXXfGPZyESZZ6YYfVRIZTrh2eRr6Y0J0SObsog4M+FbvIZEJ8CiN jAErtRh3ZPx1RRytPd5s2l9bMnUAMOLvEFTI/l/Eirp3izRRjLW9JX6yROiMrA== ARC-Authentication-Results: i=2; aspmx1.migadu.com; dkim=pass header.d=excalamus.com header.s=zmail header.b=cYC5PLz1; 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=none; arc=pass ("zohomail.com:s=zohoarc:i=1") ARC-Seal: i=2; s=key1; d=yhetil.org; t=1710705757; a=rsa-sha256; cv=pass; b=YE0VOY03qdgaJQxONU/izO2KxEcXCFUSD+sIhVR9byAwBIhWuybwaCV/f7aADdTQo1rtua 6ANunGZm5G8vd3T/HHIVF0vxTut8+l4+CBVyqiuWFFteoOhGVrx6pF1jVtZI9h6+pYHHzq AqdlfX34Lh9e3swrkcZHXXp+ny8PVWv9MxHSA2yoGK7AwIL2bm/9edWLCTRJu4e43hEWVC mg3SiXsMftwm1dSCzhyWom2H3vCQPkqYww9XCNm9xJuMQhYa9u8SjPcpqvp5MwYn1IgqeO L8GQqQ9yy9OjDNvfF+bVVMhcQdkt3YJ4K1vODwTP8CUZ3Vla/hqcOHaPnvqbgA== 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 332DF44D5B for ; Sun, 17 Mar 2024 21:02:37 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rlwhg-0008QJ-Uh; Sun, 17 Mar 2024 16:01:56 -0400 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 1rlwhd-0008OO-9H for emacs-orgmode@gnu.org; Sun, 17 Mar 2024 16:01:53 -0400 Received: from sender4-pp-f112.zoho.com ([136.143.188.112]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rlwhY-0002Zu-Cu for emacs-orgmode@gnu.org; Sun, 17 Mar 2024 16:01:51 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1710705702; cv=none; d=zohomail.com; s=zohoarc; b=eIo//0SZe8L/fXy0V3qsraIK8Pub22Fhlolj7fndJtuSqT+5vWXWGJ+pHZmiYE7MToVRISS71CIy47iJ5+8X49ZXHy729qiY9gvfAaz6hNl/VmSrnTtedMShyKj+UCDAWDQYvaS4uQM7QLKE9RYP+4k6fPwHXKjpDRb6SxByWpQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1710705702; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=ZNOA9mzKDHiyaM7WKj14u4jkJz6IA3WwZAT6PINx6j8=; b=PplZXeUjWfWghsCUB1iaFhe5kREUNL0YU0y229I45L9tOPg4vfvLMfIpiXYvDEe+Yigy3joO2JRMzHSZwG/biXsMglVo7DiB9E4QKDvnqB4gtjM1gtK0RYsnJbwiIi0OFxPUgrrwxguwhzb8QJIoMP8aet27JW808EMSzcLaW1s= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=excalamus.com; spf=pass smtp.mailfrom=matt@excalamus.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1710705702; s=zmail; d=excalamus.com; i=matt@excalamus.com; h=Date:Date:From:From:To:To:Cc:Cc:Message-ID:In-Reply-To:References:Subject:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-Id:Reply-To; bh=ZNOA9mzKDHiyaM7WKj14u4jkJz6IA3WwZAT6PINx6j8=; b=cYC5PLz1zEOniHwrAl1eWw8ZzgukSZgguy+HibYkgDliM2f2wQj9XiLi6JBnu0Tc onEBilwx2E2Dee9DqNnxL61bFpiq1LJKMpIen7XgidyPBO9psGGpaegHwhZWWbe4oN2 c4Jq6U1pa7njwm4uHkaawZDCrJ3JhEQfZTqKn/5A= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1710705701265497.1573520696039; Sun, 17 Mar 2024 13:01:41 -0700 (PDT) Date: Sun, 17 Mar 2024 21:01:41 +0100 From: Matt To: "Matt" Cc: "Ihor Radchenko" , "emacs-orgmode" Message-ID: <18e4e01717d.b1bd307a696132.1612686871442583784@excalamus.com> In-Reply-To: <18e4deaa1bd.ff0f87fa694858.5955779335024266818@excalamus.com> References: <18d753c1e8a.cfb3e1921191837.5665565128507976741@excalamus.com> <87ttmn9fg0.fsf@localhost> <18dbc1f273c.11687295c1395973.3345700621594100711@excalamus.com> <87ttm4g14s.fsf@localhost> <18e4deaa1bd.ff0f87fa694858.5955779335024266818@excalamus.com> Subject: bug? org-babel-comint-with-output return value type MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail Received-SPF: pass client-ip=136.143.188.112; envelope-from=matt@excalamus.com; helo=sender4-pp-f112.zoho.com 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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-Spam-Score: -8.72 X-Spam-Score: -8.72 X-Migadu-Queue-Id: 332DF44D5B X-Migadu-Scanner: mx13.migadu.com X-TUID: cPNXzxO6pbi8 Looking at the last patch of https://list.orgmode.org/18e4deaa1bd.ff0f87fa6= 94858.5955779335024266818@excalamus.com/, I would expect a reaction of some= thing like, "WTF is all that weird org-trim string-join stuff on the prompt= filter?" --- lisp/ob-comint.el | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lisp/ob-comint.el b/lisp/ob-comint.el index d13aacccc..f2251892a 100644 --- a/lisp/ob-comint.el +++ b/lisp/ob-comint.el @@ -325,9 +325,10 @@ STRING contains the output originally inserted into th= e comint buffer." =09=09 until (and (equal (match-string 1) "start") =09=09=09=09 (equal (match-string 2) uuid)) =09=09 finally return (+ 1 (match-end 0))))) -=09=09 ;; Apply callback to clean up the result -=09=09 (res-str (funcall org-babel-comint-async-chunk-callback - res-str-raw))) + ;; Remove prompt + (res-promptless (org-trim (string-join (mapcar #'org-tr= im (org-babel-comint--prompt-filter res-str-raw)) "\n") "\n")) +=09=09 ;; Apply user callback +=09=09 (res-str (funcall org-babel-comint-async-chunk-callback res-promp= tless))) =09 ;; Search for uuid in associated org-buffers to insert results =09 (cl-loop for buf in org-buffers =09=09 until (with-current-buffer buf --=20 2.41.0 The reason is that the current result of =3Dorg-babel-comint-with-output=3D= is a list because the final expression is =3Ddelete=3D: https://git.savann= ah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ob-comint.el?id=3D46909a54e1a2= ce0d948e94e0e19ff64af1a39eb9#n164 Why =3Dorg-babel-comint-with-output=3D returns a list is unclear to me. Th= e docstring for =3Dorg-babel-comint-with-output=3D says it should "return a= ll process output". AFAIK, process output is a string, always has been, al= ways will be, and Babel has always gotten a substring of the process buffer= (for that code path). Yet for some reason, it was decided to have =3Dorg-= babel-comint-with-output=3D return a list. This goes back to the beginning= , in 2009, when the final expression used =3Dsplit-string=3D instead of =3D= delete=3D: https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/lisp= /org-babel-comint.el?id=3Ddd0392a4f23b40fae7491c55aa44a2324248c103 You might ask, "But wouldn't returning a list require you to then convert i= t back into a string since =3Dorg-babel-comint-with-output=3D is really jus= t a sentinel on process output?" The answer is, "Yes, that's exactly what = you'd need to do." Call grep on =3Dorg-babel-comint-with-output=3D and you'll see in every cas= e except the Ruby ':results value' results and Lua the ':results value' res= ults, that indeed the return value of =3Dorg-babel-comint-with-output=3D is= concatenated or the first string element taken. | file | line | result modified? | result used? | comment = | |---------------+------+--------------------------+--------------+---------= ---------------------------------------------------------------------| | ob-ruby.el | 263 | no | no | used to = send eoe-string | | | 272 | yes, mapconcat | yes | as retur= ned value (for :results output) | | | 281 | no | yes | as retur= ned value (for :results value) | |---------------+------+--------------------------+--------------+---------= ---------------------------------------------------------------------| | ob-js.el | 111 | yes, nth 1 | yes | as retur= ned value (for the default :results) | |---------------+------+--------------------------+--------------+---------= ---------------------------------------------------------------------| | ob-shell.el | 357 | yes, mapconcat | yes | as retur= ned value (for session results of all types) | |---------------+------+--------------------------+--------------+---------= ---------------------------------------------------------------------| | ob-julia.el | 327 | yes, mapconcat | yes | as retur= ned value (for :results output) | |---------------+------+--------------------------+--------------+---------= ---------------------------------------------------------------------| | ob-lua.el | 391 | yes, mapconcat | yes | as retur= ned value (for :results output) | | | 400 | no | yes | as retur= ned value (for :results value) | |---------------+------+--------------------------+--------------+---------= ---------------------------------------------------------------------| | ob-haskell.el | 169 | yes, (cdr (reverse ...)) | yes | as retur= ned value? (for :results output) hard to tell, see lines 194 and 201 | |---------------+------+--------------------------+--------------+---------= ---------------------------------------------------------------------| | ob-octave.el | 239 | yes, (cdr (reverse ...)) | yes | as retur= ned value (for :results output) | |---------------+------+--------------------------+--------------+---------= ---------------------------------------------------------------------| | ob-ocaml.el | 72 | yes, whoa... | yes | as retur= ned value (for at least :results output) | |---------------+------+--------------------------+--------------+---------= ---------------------------------------------------------------------| | ob-R | 460 | yes, mapconcat | yes | as retur= ned value (for :results output) | |---------------+------+--------------------------+--------------+---------= ---------------------------------------------------------------------| It looks like the original implementation aggregated process buffer output,= collecting it into a list. It then passed this list on to a function that= did, as predicted, (cdr (reverse ...)) to get a string. https://git.savan= nah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3Ddd0392a4f23b40fae7491c55aa= 44a2324248c103 It seems like the return type of =3Dorg-babel-comint-with-output=3D is not = what it should be. It looks like it should be a string. Am I missing something? Obviously, changing the return type would be a big job, requiring updates t= o at least 10 files, and has the potential to introduce bugs. However, as = far as I can tell, the return type isn't appropriate and so requires some k= ind of workaround, of which there are currently three. I guess the best ar= gument I can come up with at the moment for taking on the task of changing = the return type is that, assuming my understanding is correct, the current = implementation is simply an inappropriate, or outdated, design choice that = only adds complexity. My hope is that Babel continues to support new langu= ages. As that happens, they will need to apply work arounds, further entre= nching the design and making it harder to correct. What are people's thoughts on changing the return type of =3Dorg-babel-comi= nt-with-output=3D? -- Matt Trzcinski Emacs Org contributor (ob-shell) Learn more about Org mode at https://orgmode.org Support Org development at=C2=A0https://liberapay.com/org-mode