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 ms1.migadu.com with LMTPS id SDMbGfDkYmamEQAAqHPOHw:P1 (envelope-from ) for ; Fri, 07 Jun 2024 12:46:08 +0200 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 SDMbGfDkYmamEQAAqHPOHw (envelope-from ) for ; Fri, 07 Jun 2024 12:46:08 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=A6F6+vcx; 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=1717757168; 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=Pinq4EjUME5qoLB5deC4oAZVOa4i9d9qr2poR1cs6/U=; b=iKDgJ0PO7c8C3eeEhT1J+Kg18OVofMxlWbgYbQFtx9Ys4/LWo3n0XwFUaYE7oFnh0bG0ig irfCdJUyPa5hSHujSvdPK/M1hLwRiEL8bN5zi/78VcYCI+BSQCwzp8yys8KwSvrwpf3cdX WRFwVLIlFos5S1GalswZoc8ellvwr7Y9Joa6MccOq/uYV3BF3uWT4URV9Zfdq6zEjpZ0DS chsZlK5lbktRRdy98ivHARDTmSbS//czPSDP7YwRAFDNkrkXcY9sXPEC2MB08pqEwSKa7U lHudYM4QkHzBk5CMAgdmXiJ20tzFy7cAG7ZdnufpAElcwVE6exJfoV9NZvHyWQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=A6F6+vcx; 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=1717757168; a=rsa-sha256; cv=none; b=hdVHJED9jZqpjggo7OKY2qT84mL6STg2HEgeKjTr4bH5diDofLF2g0+FXp4B/HyDtu37/A LEqsYDsWZ2YPd7kAlCN4vZAGN/dKvJ5fxdzINJ8dPUK3uFHnxmw1SmKM8MIQFso1JKoWB2 KlAywYuq+EoUh4/4ugXUEjmYoSuco50YgAeGTrm+Pfv1EDkKN1mzDfVvB296sePBpEd62Z mbVyyrsmlDmBxlmA0T+8bU7tkc8l7RChMvEIanxyVJJdDut99owCc6MxL01y+j/Bilnjx1 Dqi1bjOTISovxwGEcFmjqAxsqStYDsHtUHWYjW+x3O3hMVKJzasF6PFXfnekjw== 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 7CB9364227 for ; Fri, 7 Jun 2024 12:46:07 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sFX5v-0007Oo-VI; Fri, 07 Jun 2024 06:45:16 -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 1sFX5t-0007OX-MG for emacs-orgmode@gnu.org; Fri, 07 Jun 2024 06:45:13 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sFX5q-0003fE-Kh for emacs-orgmode@gnu.org; Fri, 07 Jun 2024 06:45:13 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id E62EA240101 for ; Fri, 7 Jun 2024 12:45:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1717757107; bh=cmM4QuzdBRSIBjQqsoRkSuc1388GBxU5Tju9U/qa4jE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=A6F6+vcxcMv2wKGO0qa/vhFx50EtDfkNknj1BlAPDSeDqgEtzjM0k/1hiskvymWrb csuME1Qlf6BytJGKclSWql6utKfBfD180drCiqokB/Ff5xhgzWWdluu+oZLBoomzME p7BEeXyJxRVY2KI1aqai6xPQgTVN6ziWYCkNRbmXn8MKLnI2oCR9E6KC9HLGdYUqdX irUA+hxam+2fWtT1hZ/SVYZDYkXBvC9w4ALqGmLjEJnrTdOhVaCNtDqbPbcZq4agy4 vDqJit3QcQ6zc9VEqm934GY8ly+MwO+xWe1bWjTRhskeWxPVnESh9LIzm6v4gvz+C0 sCVx87UAeycrg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VwdBW01wHz6ty3; Fri, 7 Jun 2024 12:45:06 +0200 (CEST) From: Ihor Radchenko To: "Berry, Charles" Cc: Jeremie Juste , Jack Kamm , Giuseppe Pagnoni , "emacs-orgmode@gnu.org" Subject: Ideas for improving ob-R (was: [FR] Org babel: mixing multiple outputs (was: Output of R code block: only text or plot but not both? And only one "result" can be output?)) In-Reply-To: <61BAA873-84A1-4696-ABC5-9A935FB1FA91@health.ucsd.edu> References: <279D1AD1-F38A-4442-AE06-60CFA0798874@health.ucsd.edu> <87cyov5k63.fsf@localhost> <61BAA873-84A1-4696-ABC5-9A935FB1FA91@health.ucsd.edu> Date: Fri, 07 Jun 2024 10:46:48 +0000 Message-ID: <87cyotghd3.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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_H3=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.56 X-Spam-Score: -9.56 X-Migadu-Queue-Id: 7CB9364227 X-Migadu-Scanner: mx13.migadu.com X-TUID: LdnI+Y3NrK9v "Berry, Charles" writes: >> Thanks for sharing the project! >> Although, I would not call going through double export, and producing >> html output "easier time". >> > > The `easier' part is that knitr/Rmarkdown requires very little markup > to produce nice documents in various formats (pdf, html, Word, > ...). And dealing with R code and markup of the results of R code for > use in documents is what that environment is attuned to, so getting a > desired result often seemed easier to me in that environment. So does Org markup... What we may be missing is nicely formatted output of R blocks, where we need something akin ob-python that knows about how to typeset various Python types in Org - data frames, graphics, tables, etc. > In terms of my usual workflow, the double export (with ox-ravel and an > `org-render` helper function loaded) requires these keystrokes: > > `C-c C-e r m M-x org-render RET` > > or subsequently > > `C-u C-c C-e M-x M-p RET` > > which adds only two keystrokes. I understand. My point is different - what if you do _not_ need HTML/pdf/word output and just want to work with the interactive notebook? Then, your export workflow is a huge overkill and complication. >> While we are here, are there any other features you find missing in Org >> babel that are present in knitr/Rmarkdown/quarto? > > `:session :results output` handling in R lang src blocks can fail as > the heuristics for finding the output of a command in the session > buffer and removing the prompts have limited success. An ECM: > > #+begin_src R :session :results output > cat("2 > 1\n") > #+end_src > > There are workarounds, of course. Hmm. We can address this, as we already do in ob-shell. The idea is to change the prompt string to something unique. Or, alternatively, we can redirect output to file using `sink'. > I recall hearing that `comint.el` would someday be replaced by a > hardier package, so maybe if/when that happens this can be cured. Such replacement is not in sight, unfortunately. > A big motivation for creating `ox-ravel' was to be able to cache large > objects. I know the `:cache` header arg helps for small objects that > require a lot of computation, but AFAICS does not help once the object > size gets large. The caching options [1] of knitr and friends are > flexible and powerful enough to support the genomics work I do. > [1] https://yihui.org/knitr/options/#cache Org mode uses pretty much the same caching mechanism (md5 checksum for code+block parameters) to save code block results. Except that cached data is not persisted between Emacs sessions. It is not too hard to make it persistent though - we have a dedicated org-persist library for such purposes. Patches welcome! I guess what is not available is caching for sessions. Can also be implemented, but it would be a slightly more complex patch. > I mentioned above that knitr is attuned to working with R > code/output. The handling of warnings, errors, and messages resulting > from R code has a number of useful options under `Text Output` [2]. > [2] https://yihui.org/knitr/options/#text-output I looked through the available options and most of them are already supported by Org mode. The ones that are not supported are: warning: (TRUE; logical) Whether to preserve warnings (produced by warning()) in the output. message: ... error: ... Fine-grained control over warning/error/message/output separation is something that would be nice to have indeed. Not just for ob-R, but in general. For ob-R, it should be fairly easy to do - we can redirect stderr/stdout output to different files and then read the results from there. > I guess a rewrite of ob-R.el to implement such features as object > caching and error/warning/message handling is feasible, but would > require a lot of effort. I believe that sufficiently motivated person familiar with R and Elisp can implement these features within a week, working in the evenings. But, as usual, it is a question of volunteers. > ... And since those features (and more - like > animation support) are already implemented in the knitr/Rmarkdown > domain is it really worth pursuing? Animation support is indeed tricky. Although, we do have an attempt in https://github.com/alejandrogallo/org-inline-webkit (any volunteers to polish that demo up to the state mergeable upstream?) As for "already implemented", it is a question of use case. knitr/Rmarkdown are fine as long as they fit the workflow, but Org mode is generally more flexible - it has more stable and sophisticated markup and can export to more formats. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at