From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 8FQgEx5XMmVTNgEAauVa8A:P1 (envelope-from ) for ; Fri, 20 Oct 2023 12:31:58 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 8FQgEx5XMmVTNgEAauVa8A (envelope-from ) for ; Fri, 20 Oct 2023 12:31:58 +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 1336C44C8D for ; Fri, 20 Oct 2023 12:31:57 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=rootshell.ro header.s=default header.b=GJxnT4WO; 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1697797918; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=Eghf7oYnNBQ39v99pT5DtxfKpgqaZqWPPPxpLnXUIL0=; b=flIdYtont/NcU0+P5/rwe1Bw86v1N34TgQuVz8e2QBVrtKy11IoQWSC+cknT9SENtxgeX2 UiuqSXIZyECVww6i7E3wtlJK/uNYgB4VbpRQBwm/PlzE/A3N5VATy9azGmZ0/FxqoWohxB I+FMzq+cIl2s2lECgUcjZOG5Jyj7z6kCFEfZ/JzvCFCDHLVtiItvhO0AQZ+qMg7ZAwKq3y pl8alCPq6VjexYRHfTEJs3N4JItm5UGZo7Z5i9/kODmFtMKvstbc023UDlc2WJBlBNcxif 2qDJAkoyUVHgJov/Z8XMACvTGxeo04VmQ/J5QJdpxFZm35ZuiC4Simxvpe8DwA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=rootshell.ro header.s=default header.b=GJxnT4WO; 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-Seal: i=1; s=key1; d=yhetil.org; t=1697797918; a=rsa-sha256; cv=none; b=UF9IzOq+uidYEtt3RphpXzXFSFDEn2wYPgduzC5cDdijZkKmWbYYqB95RzSDzZ1KAUOkdy cZQV3l2sdVphfLjOfQr2YzDXPzW27u50/R2YHbFfnFolb7n2/QhkHevs/L8L+dggAgWBnU CzdQJ+iId1h0loh/YXjPSbMT9f98S9Iz0mXWImS6jc9CFTb8LVxLYWS8fayLA/BQD+8R2b whDDwVaaFErrHHLY6nQ3uD3Tm/It7Fbrjm8cqkFk6nwu82BHFUMssKxHf88gadeXob22qp 2DFkk21z2Jy6leGQgnxXAbk41aMaJzGHiRhrmJ8hE+KZMoaG71zai3aAawqpMg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtmmN-0001bO-E4; Fri, 20 Oct 2023 06:30: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 1qtQlP-000252-Py for emacs-orgmode@gnu.org; Thu, 19 Oct 2023 07:00:27 -0400 Received: from bowling-cafe.ro ([82.79.32.74] helo=mail.rootshell.ro) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qtQlM-0004wo-Fr for emacs-orgmode@gnu.org; Thu, 19 Oct 2023 07:00:27 -0400 Received: from localhost (unknown [IPv6:2001:4091:a247:8043:5e6c:1935:876f:4b12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.rootshell.ro (Postfix) with ESMTPSA id D1E53264DA for ; Thu, 19 Oct 2023 14:00:00 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=rootshell.ro; s=default; t=1697713202; bh=WuIhgAvc7+2Kq8qjJHv5tOOiNx2g2cgQhEki4fNkgqQ=; h=Date:From:To:Subject:From; b=GJxnT4WOwv2Pev7awLj1orwZMD77l87oklob8WWcYeZnrTntFAy1HavTBACSg+nQr AlFogHwYw/Xerh0ErLJxuAGZTSxb6nfEOgTabpyi82KQ+UrmjCH3zbRpy4K4KRvDpI Z6z9CkPUhGdQUbGRdJ5FXFfNR/JOPq9C0nSyJ7ZkVQLDdiKcl16Z/13nmVPaFPgnMm MCxhDq8bCGHv/4lh2aIHCLJstnPtgOB3RAPKA1qonLaHjNY4O00jvfU7/09QKTQpdH hxe07pK4mSikV+Fz/6YKLW8EiTe55qpsPTCPCkgPILzZMTjsHdGKBqcwHsMYFJS2vU IRr3Wtge8xhpw== Date: Thu, 19 Oct 2023 12:59:59 +0200 From: Florin Boariu To: emacs-orgmode@gnu.org Subject: org-ditaa woes Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=82.79.32.74; envelope-from=florin.om@rootshell.ro; helo=mail.rootshell.ro 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 20 Oct 2023 06:30:50 -0400 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 X-Migadu-Spam-Score: -3.32 X-Spam-Score: -3.32 X-Migadu-Queue-Id: 1336C44C8D X-Migadu-Scanner: mx2.migadu.com X-TUID: cr3L70Gh7qeT Hello everyone, I am not on the mailing list, so I'm hoping that some kind soul with moderator powers will have mercy and let my email through in a timely manner :-) Also, please CC me in on the answer. (I'll happily subscribe if you feel that I should, but this is likely to be my only encounter with the Org-mode list, so it's probably bogus...) To my problem. What did I do ============= I was trying to create a diagram e.g. from the following org-mode snippet: > #+begin_src ditaa :file network.png > > +------+ > | moo | > +------+ > > #+end_src My init.el eventually gets to parse this configuration: > (org-babel-do-load-languages 'org-babel-load-languages '( > (python . t) > (ditaa . t)) > ) > > ;(setq org-ditaa-jar-path "/usr/bin/ditaa") > ;(setq org-ditaa-jar-path "/usr/share/java/ditaa.jar") > ;(setq org-babel-ditaa-java-cmd "/usr/bin/ditaa") > ;(setq org-babel-ditaa-java-cmd "flatpak-spawn --host toolbox run ditaa") There are several attempts on setting org-ditaa-* variables, or org-babel-ditaa-*, but all fruitless (see below). I pressed C-c C-c in order to have a diagram generated. What did I expect would happen ============================== The documentation says that a "#+results" section will appear, and it will contain a link to the ditaa document. Obviously I'd expect to have a network.png file appearing somewhere on my filesystem, too, or a PNG inlined into my ORG document. Or something. What happend instead ==================== A "#+RESULTS: ..." section with [[file:network.png]] does indeed appear, but no network.png is to be found anywhere. Clicking on network.png only opens a new and empty buffer named "network.png", without any contents. Essentially, the error messages I find in '*Messages*' so far vary, depending on which org-ditaa / org-babel-ditaa variables I set, and how I set them. They range from: > org-babel-execute:ditaa: Could not find ditaa.jar at /app/share/emacs/29.1/lisp/contrib/scripts/ditaa.jar via: > Error: Invalid or corrupt jarfile /usr/bin/ditaa Code block evaluation complete. to: > Error: Unable to initialize main class org.stathissideris.ascii2image.core.CommandLineConverter > Caused by: java.lang.NoClassDefFoundError: org/apache/commons/cli/ParseException > Code block evaluation complete. I'm fairly sure I know *why* this is the case, just not how to fix it. ...actually, I'm fairly sure that it can't be fixed on my part :-( Essentially, emacs / org-babel tries to either execute "java -jar /usr/bin/ditaa", or doesn't find any jar file, or finds one in /usr/share/... but fails to actually make it run. A little bit more background. I have what would be considered an "exotic setup", although it's pretty standard for the Linux distribution I'm using (Fedora Silverblue): - My Emacs (29.1 apparently?) runs in a Flatpak - All other applications, including ditaa, run in a "Toolbox" (https://containertoolbx.org/). Think: kind of a "mutable Docker container". Think of it as of a chroot'ed environment where everything else that isn't X-windows or Gnome is installed, and that only shares /home/me, /var, and a few other non-relevant directories with the host system. In particular, it does *not* share /usr, /bin, /lib or anything of importance for applications. - ...alternatively, I can run an Emacs instance (a 28 version) in the same toolbox as the other applications (i.e. ditaa), but the results are the same. - ditaa within the toolbox is my "distribution standard", which is an executable file at /usr/bin/ditaa, and which apparently is a shell script with the following contents: #!/usr/bin/bash # source /usr/share/java-utils/java-functions MAIN_CLASS=org.stathissideris.ascii2image.core.CommandLineConverter BASE_JARS="ditaa commons-cli xml-commons-apis batik" set_classpath $BASE_JARS run "$@" This is to show that it's similar to, but still quite a bit more than just "java -jar ditaa.jar ...". This appears to be standard e.g. for all Fedora distributions (and alike). FWIF, latest Debian does something similar, only that /usr/bin/ditaa there is a binary. The core of the problem ======================== Essentially, org-ditaa expects a jar and a java runtime to be able to consruct a command line of the kind "java -jar /path/to/didaa.jar ..." and expect everything to sail smoothly. And it's *very* opinionated about that. There's no way that I can provide that without a significant amount of ugly hacking. What I can offer are a myriad of workarounds, but all boil down to specifying a shell command that does what org-ditaa expects, but doesn't begin with "java -jar ...". This is simply because the premise -- namely that emacs, org-ditaa, ditaa.jar and java-runtime, are in the same filesystem namespace, or the same process namespace, is simply not true for me. This is by design -- both of the distribution I'm using, and of the whole Flatpak ecosystem. Where to go from here? ====================== So... yeah. This is where I stand. What options do I have? Besides the obvious "use another distribution" I essentially have two options, and they both begin with "download a fresh ditaa.jar from Sourcerforge, independent of the one distributed with your Linux, and then...": 1. either patch the Flatpak to actually include this, and refer to it from org-ditaa-jar-path, or 2. copy it somewhere into your "toolbox" filesystem namespace and refer to it from org-ditaa-jar-path, "...and then do this again every time you update your Flatpak or your Toolbox (which is every couple of days)." Now that I think of it, there is actually another one: 3. Manualy download and put a ditaa.jar somewhere in "~/.emacs.d/..." (the home folder is persistent even in most sandboxes). But Flatpak-emacs doesn't include a java runtime, so I'd still be stuck at "java -run ...". However, this would at least enable me to work with my toolbox-emacs -- albeit at the cost of having to manually download a .jar file, of which a perfectly fine copy is delivered by my distribution's package management already. I wasn't able to find in-depth documentation on how to manipulate command lines for org-ditaa (if there is any available, please kindly point me in the right direction -- I looked mainly at https://orgmode.org/worg//org-contrib/babel/languages/ob-doc-ditaa.html and https://github.com/bzg/worg/blob/master/org-contrib/babel/languages/ob-doc-ditaa.org and various stackoverflow and github bug reports.) But in the source code of org-ditaa.el (https://github.com/tkf/org-mode/blob/master/lisp/ob-ditaa.el) I can see something like this on lines 87 ff: > [...] > (cmd (concat "java " java " " org-ditaa-jar-option " " > (shell-quote-argument > (expand-file-name > (if eps org-ditaa-eps-jar-path org-ditaa-jar-path))) > " " cmdline > " " (org-babel-process-file-name in-file) > " " (org-babel-process-file-name out-file))) > [...] I suck at LISP, but I'm guessing this means that there simply is no way of just passing on a "/usr/bin/ditaa" command-line to "org-ditaa", or at least an alternative Java command like "flatpak spawn --host /usr/bin/java ...". Org-ditaa really *does* insist of glueing it together from "java -jar ..." pieces, and is stubbornly adamant on finding Java in the same FS namespace. Is there a deeper reason behind this? This pretty much breaks Flatpak, or any other sandboxing compatibility, as far as I understand. Can it be changed? Please? :-) How can I make it accept a command line? Is there any "generic" way of making org-babel accept a command line, not necessarily going through "org-ditaa", as a workaround? Thanks & cheers, Florin. -- "Socks come in pairs. If you put a sock on your left foot, the other sock of the pair instantly becomes the “right sock,” no matter where it is located in the universe." -- quantum entanglement explained on /.