From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id UA/iCe5GPGNXjgAAbAwnHQ (envelope-from ) for ; Tue, 04 Oct 2022 16:45:02 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 8BwSCe5GPGPxFgAAG6o9tA (envelope-from ) for ; Tue, 04 Oct 2022 16:45:02 +0200 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 9F3B930D88 for ; Tue, 4 Oct 2022 16:45:01 +0200 (CEST) Received: from localhost ([::1]:46504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ofjAJ-0007YD-Sv for larch@yhetil.org; Tue, 04 Oct 2022 10:45:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42684) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofiTD-00073V-3A for emacs-orgmode@gnu.org; Tue, 04 Oct 2022 10:00:27 -0400 Received: from mail.hostpark.net ([212.243.197.30]:51464) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ofiTA-0002I9-Go for emacs-orgmode@gnu.org; Tue, 04 Oct 2022 10:00:26 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 44A0A16586; Tue, 4 Oct 2022 16:00:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from:received :received; s=sel2011a; t=1664892020; bh=50NDoqDjvlQen3W0wfiqSVmx rcS4em21ZbE+qEkwDrU=; b=Ioj4jtCKPR8fM7oEca722eM7u6BtLi7v+nz0F949 qq2sL0LsoEeBfoFWB7YT9epdDEbdGg2ACid3qaHiOIlgsyH+KDtMlr6mqKbo06q9 qvm9B6TVOop+bsxGf21G5vYGiD6ricnUVN/6OzB9N5Bw4O9nzqpocai7uMbzWLjk iTI= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id HFSR46eF2Cmt; Tue, 4 Oct 2022 16:00:20 +0200 (CEST) Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 13E8416574; Tue, 4 Oct 2022 16:00:20 +0200 (CEST) From: Jonas Bernoulli To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Subject: Re: Post-process table without changing result for empty table(/list) In-Reply-To: <874jwkwb4c.fsf@localhost> References: <871qrovh7g.fsf@bernoul.li> <874jwkwb4c.fsf@localhost> Date: Tue, 04 Oct 2022 16:00:19 +0200 Message-ID: <87sfk3u1sc.fsf@bernoul.li> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: none client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1664894701; 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=Dh9WtqtTkrYSlaWDykVCtmYxIkX/2gSa86p5JcOihq0=; b=Tp5eeEiXui4VFVh86MloQBIZSiKpSs66l+5Z7zrMD+1r1R0vI+18vsq3+asjEuyw7rP41C hTuhW6QhzNtp3BMgWgz1ISzSWhISc8uZY07q1w8+GvHTxIqptCFHTtTLb8L677tL2RuHOB 57GXV59leqbVz21VW2ZQEOArMxX4wheXL/TVoGqkWcw6XyBtPqUOL0fSxt47vqDPP3GUoE yKnNaqKGt2N4Wg9WUzmrnvdJlc3vs1ykAERwBRY6UOjOaOJQLEIisUntc+zsorTL6C9Lcw 2Do/djqcjPldfLbJOXHarW/kUamV02ax0F+22c0f6mVVveL5FGirWHO/9Jix6Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1664894701; a=rsa-sha256; cv=none; b=ZS+v6cAfq/R5Q7c2UFdTWFZO7dc2MLdRVGmrv47FszFz40gcCaoexNjWOVVR7VbWC/l5T8 Kq8+w60XGk11ck4l3O0HJCcONkr9zlbNCKOG8wGl3tDFHQeDEdPFRUvsQrZ4JssiZAzZ4C b8xSSqzH73Llhq4ItYHO6lVsWKdBnkFQv8u6zlsMnywhSSWouLkS+HXeVnTvURU9RIPCXI fcTuI0yUx3Vu8Ii25OAsVhqwAponeBpsIHMoHWfJ2Lk49Fik3cAAd3apxjrL2ybeMFO8D2 VRnlQp4oyyr6wBsdR4cZem0jgmC/W+glIg9n7weu2J1ZKT4Zja9eoJvyfGkoyQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=bernoul.li header.s=sel2011a header.b=Ioj4jtCK; dmarc=none; 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" X-Migadu-Spam-Score: -1.96 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=bernoul.li header.s=sel2011a header.b=Ioj4jtCK; dmarc=none; 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" X-Migadu-Queue-Id: 9F3B930D88 X-Spam-Score: -1.96 X-Migadu-Scanner: scn1.migadu.com X-TUID: VEZ/N9SMciGP Ihor Radchenko writes: > Jonas Bernoulli writes: > >> It used to behave like that before 51a628bc5efc from 2009, which started >> turning all symbols, including nil, into strings, but without giving any >> reason why that should be done. >> >> It has worked like this for a long time now, so reverting that is >> probably not feasible in the short run. However, I feel it would >> make sense to change now how nil/'() is treated. Currently it is >> being treated as the symbol nil, but IMO it would make more sense >> to treat it as the empty list. That could be achieved with >> >> diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el >> index b79e47900..2b4a16aea 100644 >> --- a/lisp/ob-ref.el >> +++ b/lisp/ob-ref.el >> @@ -199,7 +199,7 @@ (defun org-babel-ref-resolve (ref) >> (org-babel-execute-src-block nil info params)))) >> (error "Reference `%s' not found in this buffer" ref)))) >> (cond >> - ((symbolp result) (format "%S" result)) >> + ((and result (symbolp result)) (format "%S" result)) >> ((and index (listp result)) >> (org-babel-ref-index-list index result)) >> (t result))))))))) > > Looks reasonable. > Could you please prepare a patch and possibly also add a test that > covers your use-case to testing/lisp/test-ob.el? > See https://orgmode.org/worg/org-contribute.html Will do. >> In the long run you might want to consider not turning any symbols >> into strings, at least not when the "regular" block as well as the >> post-processing block both use elisp. > > This may be tricky. Introducing any kind of special case will make the > code fragile. We should better make things as generic as possible. By "special case", do you mean "just for elisp", or "if both use the same language, whatever that might be"? IMO it would be best if as much information were preserved between the two code blocks, and when they use the same language, that should be "all of it", or nearly. If they use the same language that might be fairly easy to do (bypass the code that previously prevented it), but of course it would be preferable if all type information were preserved between any two block. But that would be harder, which is why I would suggest to first/only do it if the same language is used by both blocks. The actual suggestion to do it only if both block use elisp, was more about first trying it with the language we are most familiar with. I wasn't trying to imply it should only be done for that language. Of course, if initially only doing for elisp actually makes it harder, then doing it for all languages at once, would be preferable. --- Speaking of other languages, when I investigated the above issue, I tried whether the issue was maybe limited to post-processing blocks that use elisp. So I also tried doing it using python, but it turned out that that had the same issue, and additionally there was a somewhat related, python specific, bug: `org-babel-script-escape' doesn't handle an empty python list correctly: "['a']" => ("a") but "[]" => [] I.e., an empty python list is turned into an empty lisp vector instead of an empty lisp list. At least for python, (> (length str) 2) should probably be changed to use >=. --- And while reproducing that issue just now, I ran into an additional, unrelated issue. I didn't have python installed and when I tried to evaluate a python block directly, that resulted in an error as expected. However, when I evaluated a elisp block, which uses a post-processing block that uses python, that failed silently.