From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id KOPOAufquGXPiAAA62LTzQ:P1 (envelope-from ) for ; Tue, 30 Jan 2024 13:26:15 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id KOPOAufquGXPiAAA62LTzQ (envelope-from ) for ; Tue, 30 Jan 2024 13:26:15 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=n3kPMvHZ; 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.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1706617575; 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=K44g4UtJ2mnGvWBmoE12H+b36/MAyVyqKvtGbFuiZi8=; b=kDCNk5RTpXWCNrr/ihwE1BVdDTil4Er4WveOt9okd67FwxshOZk1w/MXMYJbAQ150qlO9H UHNaLAPvwmNv7ug8FouqluUkt9JXsTnTPtw0KQ3uiO3ULXrb1OJbI2Sq0gk5SuPBqCT+Df RzumviPaMPkw5AfGBZMsk4d8pantggrFChF52xDoXJ/tQHDhWthvxHa6sGPArzUocqOapi W/XuezaVdW/f8pbcZZcqgoQcazreYAkKfSCQIUnhvxXABOUwzqJ3vNkRfNVlHq/qMs12PD ulthw4JfE3+UQHBLrw+JDg9JVyhTHPtB4ZweDNrJJRPsie1ShM+SSs4+oWN+YA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=n3kPMvHZ; 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.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1706617575; a=rsa-sha256; cv=none; b=NPyiFUPYvLGnoj7KjpOFGDC1rqaroVl8MzD36uNujBdxn+4TuUZ2qh8uJhQAFsA8exKJfd J2o+WUZKGHzOyJ7k2Ow4swaB2rGnZRuF8sS7EiNMuPFcUWK334Wl0UA743aZbnTyzwAmZQ p527blAWMNkiIZvuDbkeZGcwKYlae27hx6QMeek919bK+6YCXkbLPf6HBTR7f3rsUqNQE/ pJvHrzmH1KXnBGdRvgPxuCp6lnl5NFgufDHDnmEx563H/KeZclAg27EjKaesOIrBPEQ3Kc 3JckCIrSYzWEKqtYTKnAmuUFnhaUIYekZaggt+4CWfKFXll+64/j7tnWX+RFxw== 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 EAE876E47F for ; Tue, 30 Jan 2024 13:26:14 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rUnB9-0002VS-UO; Tue, 30 Jan 2024 07:25:28 -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 1rUnB3-0002VK-Qs for emacs-orgmode@gnu.org; Tue, 30 Jan 2024 07:25:22 -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 1rUnAv-0007wi-Ux for emacs-orgmode@gnu.org; Tue, 30 Jan 2024 07:25:16 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 19C12240029 for ; Tue, 30 Jan 2024 13:25:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1706617508; bh=Jz9rmvXLaQLpXEkBydZbcnb0i7KsV0CyD2FKuXkgDow=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=n3kPMvHZQ3DE8IRWdvOPMQlkR5iYQOfU5ehNiDgcpPp2RjaBNJoqa7oMy/rPUO9E0 ot/Asb9ruKpM6+abCF5xW1ANMn0SFbC8hIr2S3NvWCweVnV706KKMYHRVBkhNuZo7O fq14LH9EYdCqcQyV1uuq/OExKunS2g6QF9mZ3Zat5w9EaZojl4r2LNCFL9V5o6pplT dulreDiRndjG5mCBUuAaFt88QEJEcgTaWZOjSCWsUNnKImNEN6Znrduv2FKZ1Xr+6f T9BzHpw/WNCrxq12xF5Kf8WgKTsHNsnP6a0bRMzWhdQMUcDnd1VGTO3QveX7XSdEtT 1C+UiyrdSO0NA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TPPWQ5z3hz9rxM; Tue, 30 Jan 2024 13:25:06 +0100 (CET) From: Ihor Radchenko To: Ken Mankoff Cc: Matt , Org-mode list Subject: [FR] Append wrapped results from babel block (was: Appending results from babel block) In-Reply-To: <87fryigtx7.fsf@gmail.com> References: <87sf2jwjhu.fsf@gmail.com> <18d4c963b2e.124d935012378350.8650834621085686252@excalamus.com> <87fryigtx7.fsf@gmail.com> Date: Tue, 30 Jan 2024 12:28:38 +0000 Message-ID: <87jznr80p5.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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: -9.88 X-Migadu-Queue-Id: EAE876E47F X-Spam-Score: -9.88 X-Migadu-Scanner: mx11.migadu.com X-TUID: pmBImI7N4kHA Ken Mankoff writes: >>> Weirdly, >>> >>> :results append drawer >>> >>> Appends result #2, but then inserts all results after the first. >> >> I'm not sure what you mean. However, trying it, I see bunches of >> "results-end" groups. I assume this is what you see, too? > > Yes that's what I see in general format. You ran it 3x in on second so I can't very we're seeing the same thing. But the order becomes > > 1 > 5 > 4 > 3 > 2 > > That is, 2 is appended as expected, but then 3 is inserted after 1 but before 2, 4 is after 1 but before 3, etc. This is expected, because Org mode has no way to know which drawers are related to results and which are not. Let me illustrate with an example: #+begin_src ... :results append drawer ... #+end_src :drawer: I have nothing to do with the above src block :end: When you evaluate the code block, Org mode searches for #+RESULTS: keyword to mark the results. If there is none, it adds it: #+begin_src ... :results append drawer ... #+end_src #+RESULTS: :drawer: 1 :end: :drawer: I have nothing to do with the above src block :end: Now, when you ask Org mode to append to result, it will find the drawer with #+results: keyword and insert the new result _after_: #+begin_src ... :results append drawer ... #+end_src #+RESULTS: :drawer: 1 :end: :drawer: 2 :end: :drawer: I have nothing to do with the above src block :end: If we now execute the source code block again, Org mode will have no idea that the "2" drawer has anything to do with results of evaluation, because it has no :RESULTS: keyword. Only the first drawer is considered. Hence, Org mode appends the result after "1" again: #+begin_src ... :results append drawer ... #+end_src #+RESULTS: :drawer: 1 :end: :drawer: 3 :end: :drawer: 2 :end: :drawer: I have nothing to do with the above src block :end: That's how the sequence your observe is constructed. When you do not use :results drawer, it happens so that subsequent : 1 : 2 are not creating two separate syntax objects, but are merged into a single fixed-width markup. So, appending works just fine. ---- Now, indeed, the above situation with drawers (and :wrap in general) is confusing. What we might do is modify `org-babel-insert-result' so that it unwraps and re-wraps the existing result when it has exactly the same wrap style. That might be a nice new feature to have. Patches welcome! -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at