Re: org-ditaa woes

2023-12-21 Thread Ihor Radchenko 
Leo Butler  writes:

>> Writing a patch is also welcome.
>
> Here is a patch to the documentation. It documents currently
> undocumented *features* of ob-ditaa.
>
> I have *removed* mention of work-arounds to execute scripts. I have also
> taken the liberty of re-writing the two source blocks to use org src
> blocks.

Thanks!
Applied, onto master.
https://git.sr.ht/~bzg/worg/commit/3e1c006b

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

Re: org-ditaa woes

2023-12-20 Thread Leo Butler 
On Tue, Oct 24 2023, Ihor Radchenko  wrote:

> Florin Boariu  writes:
>
>> I can offer to try my luck with writing a patch for ob-ditaa.el, but
>> I'm not knowledgeable enough (or have enough time on my hands) to
>> actually keep maintaining it :-p
>
> Writing a patch is also welcome.

Here is a patch to the documentation. It documents currently
undocumented *features* of ob-ditaa.

I have *removed* mention of work-arounds to execute scripts. I have also
taken the liberty of re-writing the two source blocks to use org src
blocks.

I will submit a patch to ob-ditaa.el (likely in January).

Leo

From 15cdaff68d3ecd1348ac8b3b3998cb146e6d5345 Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Thu, 26 Oct 2023 20:49:41 -0500
Subject: [PATCH] org-contrib/babel/languages/ob-doc-ditaa.org: update
 documentation

* org-contrib/babel/languages/ob-doc-ditaa.org: Add a subsection,
Customization Options, that documents the four DEFCUSTOM variables.
Document the header arguments eps and pdf, which control how output is
created.  Modify the existing examples so that the org code that is
exported also creates the code-blocks that are executed.

Ref: https://list.orgmode.org/ZTEML8zWrB6kQflk@toolbox/T/
---
 org-contrib/babel/languages/ob-doc-ditaa.org | 48 +++-
 1 file changed, 36 insertions(+), 12 deletions(-)

diff --git a/org-contrib/babel/languages/ob-doc-ditaa.org b/org-contrib/babel/languages/ob-doc-ditaa.org
index 0ae949c2..f2c31a49 100644
--- a/org-contrib/babel/languages/ob-doc-ditaa.org
+++ b/org-contrib/babel/languages/ob-doc-ditaa.org
@@ -57,18 +57,34 @@ Activate evaluation of =ditaa= source code blocks by adding =ditaa= to
  '((ditaa . t))) ; this line activates ditaa
 #+END_SRC
 
+** Customization Options
+Org needs to know a few things about =ditaa= and the =java= executable in order to function. The following is a list of variables that can be customized.
+
+- org-ditaa-jar-path :: The path to the =ditaa= jar file.
+- org-babel-ditaa-java-cmd :: The name or path to the Java executable used to run the =ditaa= jar file.
+- org-ditaa-eps-jar-path :: The path to the =ditaaeps= jar file. [[https://ditaa-addons.sourceforge.net/][DitaaEps]] is maintained as part of the [[https://ditaa-addons.sourceforge.net/][ditaa-addons]] project.
+- org-ditaa-jar-option :: The prefix used before the =ditaa= jar path. The default is =-jar=.
+
 * Babel Features for ditaa Code Blocks
 ** Header Arguments
-   - file :: =ditaa= source code blocks require that an output file be specified
-   - cmdline :: specify [[http://ditaa.sourceforge.net/#usage][command line arguments]] for =ditaa=
-   - java :: arguments for the =java= runtimes (JRE) 
+   - file :: the output filename (mandatory)
+   - cmdline :: [[http://ditaa.sourceforge.net/#usage][command line arguments]] for =ditaa=
+   - java :: arguments for the =java= runtimes (JRE)
+   - eps :: produce an =eps= output file using =ditaaeps=
+   - pdf :: produce a =pdf= output file using =ditaaeps= followed by =epstopdf=
+
 ** Sessions
=ditaa= does not support sessions.
 ** Result Types
 =Ditaa= source code blocks return a link to a [[http://www.libpng.org/pub/png/][png]] bitmap file.
 * Examples of Use
+** Hello World
 The obligatory Hello World! example in =ditaa=:
-#+BEGIN_EXAMPLE
+
+#+NAME: hello-world.org
+#+BEGIN_SRC org :exports code :results replace
+,#+NAME: hello-world
+,#+HEADER: :exports results
 ,#+BEGIN_SRC ditaa :file images/hello-world.png
 +--+
 |  |
@@ -76,9 +92,11 @@ The obligatory Hello World! example in =ditaa=:
 |  |
 +--+
 ,#+END_SRC
-#+END_EXAMPLE
+#+END_SRC
 
-#+header: :exports results
+#+RESULTS: hello-world.org
+#+NAME: hello-world
+#+HEADER: :exports results
 #+BEGIN_SRC ditaa :file images/hello-world.png
 +--+
 |  |
@@ -87,23 +105,29 @@ The obligatory Hello World! example in =ditaa=:
 +--+
 #+END_SRC
 
-#+RESULTS:
+#+RESULTS: hello-world
 [[file:images/hello-world.png]]
+** Passing command-line options to =ditaa=
 
 Now, round all corners by passing =ditaa= the =-r,--round-corners=
 command line switch.
 
-#+BEGIN_EXAMPLE
-#+BEGIN_SRC ditaa :file images/hello-world-round.png :cmdline -r
+#+NAME: hello-world-round.org
+#+BEGIN_SRC org :exports code :results replace
+,#+NAME: hello-world-round
+,#+HEADER: :exports results
+,#+BEGIN_SRC ditaa :file images/hello-world-round.png :cmdline -r
 +--+
 |  |
 | Hello World! |
 |  |
 +--+
+,#+END_SRC
 #+END_SRC
-#+END_EXAMPLE
 
-#+header: :exports results
+#+RESULTS: hello-world-round.org
+#+NAME: hello-world-round
+#+HEADER: :exports results
 #+BEGIN_SRC ditaa :file images/hello-world-round.png :cmdline -r
 +--+
 |  |
@@ -112,6 +136,6 @@ command line switch.
 +--+
 #+END_SRC
 
-#+RESULTS:
+#+RESULTS: hello-world-round
 [[file:images/hello-world-round.png]]
 
-- 
2.42.0

Re: org-ditaa woes

2023-10-26 Thread Leo Butler 
On Tue, Oct 24 2023, Max Nikulin  wrote:

> On 23/10/2023 18:18, Florin Boariu wrote:
>>
>>> sh-5.1$ flatpak-spawn --host toolbox run /usr/bin/ditaa
>>> /tmp/foo.txt -o /tmp/foo.png
>
> thanks
>
>> I really _need_ to generically execute a command.
>
> I hope, a couple of workarounds are still possible.
>
> 1. Get java command by adding bash -x (or /usr/bin/bash, or
> "/usr/bin/env bash")
>
> flatpak-spawn --host toolbox run bash -x /usr/bin/ditaa \
> /tmp/foo.txt -o /tmp/foo.png
>
> - set `org-babel-ditaa-java-cmd' to something like
> "flatpak-spawn --host toolbox run /usr/bin/java",
> - set `org-ditaa-jar-path' to path to ditaa.jar reported by the
>   command above,
> - add other options to either `org-babel-header-args:ditaa' :java
>   property or to `org-babel-ditaa-java-cmd'
> - perhaps add /usr/bin/env JAVA_HOME=... and other required
>   environment variables before java binary.
>
>
> 2.
> - set `org-babel-ditaa-java-cmd' to
>   "flatpak-spawn --host toolbox run /usr/bin/ditaa".
> - set `org-ditaa-jar-option' to empty string.
> - Call of `shell-quote-argument' makes it impossible to set
>   `org-ditaa-jar-path' to empty string, so set the following variables
>   to some harmless value, e.g. "-Dfile.encoding=UTF-8" (anything added
>   through :java babel header argument):
>   + `org-ditaa-jar-path'
>   + `org-ditaa-eps-jar-path'
>
>
> I agree that it should be possible to call ditaa executable
> directly. Perhaps it is not possible because for a long time ditaa.jar
> was a part of Org mode repository (there were a lot of messages
> against dropping of jar files from the repository). It seems, nobody
> is ready to take responsibility and to become maintainer of
> ob-ditaa.el while active users have no ability to install ditaa as a
> package, so they anyway have to download .jar from upstream.
>
> I find it tedious to add "flatpak-spawn ..." to every tool used by
> Emacs. Who is the publisher of the flatpak? I would expect a directory
> with symlinks named ditaa, java, git, gcc, cpp, etc to a script line
>
> #!/bin/sh
> exec flatpak-spawn --host toolbox run /usr/bin/env "$0" "$@"
>
> (or "$(basename "$0")")
>
> mounted to flatpak runtime and added to $PATH. Perhaps another
> approach exist and it should be discussed with the packager and Emacs
> developers.

Florin,

Max is right, there are work-arounds possible, although a bit different
from what he suggests. The attached org file shows how to do what you
want using the existing ob-ditaa.el code. I have also attached the
exported html document with the image created.

Tell us if it works for the version of Org that you are using.

Leo

#+author: Leo Butler
#+title: Executing ditaa from a script

* Executing =ditaa= from a script

Org assumes that =ditaa= is run as a java jar file.  Users may need to
use a script to run =ditaa=.  This example shows how.

First, set ~org-babel-ditaa-java-cmd~ and ~org-ditaa-jar-option~ to
empty strings and ~org-ditaa-jar-path~ to the script's path; here, it
is =/usr/bin/ditaa=.  This example uses ~setq-local~ to change only
the values in this buffer.

#+name: hello-world-from-script.el.org
#+begin_src org :exports code :results replace
,#+name: hello-world-from-script.el
,#+begin_src emacs-lisp :exports none :results none
(setq-local org-babel-ditaa-java-cmd ""
	org-ditaa-jar-option ""
	org-ditaa-jar-path "/usr/bin/ditaa")
,#+end_src
#+end_src

#+RESULTS: hello-world-from-script.el.org
#+name: hello-world-from-script.el
#+begin_src emacs-lisp :exports none :results none
(setq-local org-babel-ditaa-java-cmd ""
	org-ditaa-jar-option ""
	org-ditaa-jar-path "/usr/bin/ditaa")
#+end_src

Second, in the =ditaa= code-block, set the header argument =:java= to
the empty string =""=.  The =:cmdline= header argument can be used to
pass command-line options to =ditaa= via the script.

#+name: hello-world-from-script.org
#+begin_src org :exports code :results replace
,#+name: hello-world-from-script
,#+begin_src ditaa :file images/hello-world-from-script.png :java "" :cmdline -r -e UTF-8
++
||
| Hello World|
| from a script! |
||
++
,#+end_src
#+end_src

#+RESULTS: hello-world-from-script.org
#+name: hello-world-from-script
#+begin_src ditaa :file images/hello-world-from-script.png :java "" :cmdline -r -e UTF-8
++
||
| Hello World|
| from a script! |
||
++
#+end_src

#+RESULTS: hello-world-from-script
[[file:images/hello-world-from-script.png]]
Title: Executing ditaa from a script






Executing ditaa from a script

Table of Contents


1. Executing ditaa from a script




1. Executing ditaa from a script


Org assumes that ditaa is run as a java jar file.  Users may need to
use a script to run ditaa.  This example shows how.



First, set org-babel-ditaa-java-cmd and org-ditaa-jar-option to
empty strings and org-ditaa-jar-path to the script's

Re: org-ditaa woes

2023-10-26 Thread Ihor Radchenko 
Leo Butler  writes:

>> Writing a patch is also welcome.
>
> I am looking at ob-ditaa. Patching it looks within my reach.
>
> Is there no testsuite for it?

No test suite. But you may refer to testing/lisp/test-ob-jave.el to see
how to write simple ob-* tests.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

Re: org-ditaa woes

2023-10-26 Thread Max Nikulin 

On 26/10/2023 02:00, Leo Butler wrote:

I am looking at ob-ditaa. Patching it looks within my reach.

Is there no testsuite for it?


Unfortunately there is only a couple of examples at

https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-ditaa.html

Re: org-ditaa woes

2023-10-25 Thread Leo Butler 
On Tue, Oct 24 2023, Ihor Radchenko  wrote:

> Florin Boariu  writes:
>
>> I can offer to try my luck with writing a patch for ob-ditaa.el, but
>> I'm not knowledgeable enough (or have enough time on my hands) to
>> actually keep maintaining it :-p
>
> Writing a patch is also welcome.

I am looking at ob-ditaa. Patching it looks within my reach.

Is there no testsuite for it?

Leo

Re: org-ditaa woes

2023-10-24 Thread Ihor Radchenko 
Florin Boariu  writes:

> I can offer to try my luck with writing a patch for ob-ditaa.el, but
> I'm not knowledgeable enough (or have enough time on my hands) to
> actually keep maintaining it :-p

Writing a patch is also welcome.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

Re: org-ditaa woes

2023-10-24 Thread Florin Boariu 

Hello,


I hope, a couple of workarounds are still possible.

1. Get java command by adding bash -x (or /usr/bin/bash, or 
"/usr/bin/env bash")


   flatpak-spawn --host toolbox run bash -x /usr/bin/ditaa \
   /tmp/foo.txt -o /tmp/foo.png

- set `org-babel-ditaa-java-cmd' to something like
   "flatpak-spawn --host toolbox run /usr/bin/java",
- set `org-ditaa-jar-path' to path to ditaa.jar reported by the 
command above,


There are a lot of assumptions baked into this one, for starters: that
I can actually do "java -jar $PATH_REPORTED_BY_COMMAND.jar" actually
works.

It doesn't:

sh-5.1$ flatpak-spawn --host toolbox run java -jar /usr/share/java/ditaa.jar
Error: Unable to initialize main class 
org.stathissideris.ascii2image.core.CommandLineConverter
Caused by: java.lang.NoClassDefFoundError: 
org/apache/commons/cli/ParseException

路

- add other options to either `org-babel-header-args:ditaa' :java 
property or to `org-babel-ditaa-java-cmd'
- perhaps add /usr/bin/env JAVA_HOME=... and other required 
environment variables before java binary.


...and now I, despite not being a Java developer, need to figure out
how to debug the execution of a program I didn't develop (in a
language I'm not familiar with), and for which a perfectly functional
script was _already_ delivered by my distribution in the form of
"/usr/bin/ditaa" ;-)

What actually _does_ work (and what I'm currently indeed using as a
workaround) is download my own copy of ditaa.jar from their website,
put it under ~/.local/share/ditaa/ditaa.jar, and set
'org-ditaa-jar-path' to that specific value.

This still leaves me with the necessity to download a package through
a side channel which already exists in my distribution as a pacakge,
but at least I don't need to get into the bowels of Java to run it.


2.
- set `org-babel-ditaa-java-cmd' to
 "flatpak-spawn --host toolbox run /usr/bin/ditaa".
- set `org-ditaa-jar-option' to empty string.
- Call of `shell-quote-argument' makes it impossible to set 
`org-ditaa-jar-path' to empty string, so set the following variables 
to some harmless value, e.g. "-Dfile.encoding=UTF-8" (anything added 
through :java babel header argument):

 + `org-ditaa-jar-path'
 + `org-ditaa-eps-jar-path'


I'm not sure whether I had thought of that (-Dfile.encoding is not
recognized by recent ditaa, BTW, I think they have a new option for
that). I think I had, but got stuck at "set org-ditaa-jar-option to
empty string" :-D  IIRD it threw an error (the one you said it would),
and that's where I stopped investigating.

I agree that it should be possible to call ditaa executable directly. 
Perhaps it is not possible because for a long time ditaa.jar was a 
part of Org mode repository (there were a lot of messages against 
dropping of jar files from the repository).


I'm not sure having the .jar in the repository would even help in my
case, unless the Emacs Flatpak specifically also shipped with a Java
runtime. (And I think we agree that this shouldn't happen -- Emacs is
a perfectly usable OS in its own right, no need for Java on top ;-) ).
Because otherwise the .jar would be inside the Flatpak, and the
runtime would be somewhere else from where it couldn't access the .jar.


It seems, nobody is ready to take responsibility and to become
maintainer of ob-ditaa.el while active users have no ability to
install ditaa as a package, so they anyway have to download .jar from
upstream.


I can offer to try my luck with writing a patch for ob-ditaa.el, but
I'm not knowledgeable enough (or have enough time on my hands) to
actually keep maintaining it :-p

I find it tedious to add "flatpak-spawn ..." to every tool used by 
Emacs. Who is the publisher of the flatpak? I would expect a directory 
with symlinks named ditaa, java, git, gcc, cpp, etc to a script line


#!/bin/sh
exec flatpak-spawn --host toolbox run /usr/bin/env "$0" "$@"

(or "$(basename "$0")")

mounted to flatpak runtime and added to $PATH. Perhaps another 
approach exist and it should be discussed with the packager and Emacs 
developers.


It's a double-edged sword. Not every Flatpak distribution actually has
a Toolbox infrastructure, too... (Flatpak didn't get invented with, or
for, Fedora Silverblue; it was around for a long time before that. But
Toolbox did.) So for most, "flatpak-spawn --host $CMD" would be the
way to go, not "...toolbox run $CMD". And even in Toolbox systems,
there can be more than one toolbox, so some might want to run
"...toolbox run -c gcc-devel $CMD ...", where "gcc-devel" is a
specific toolbox for GCC development.

But with regards to the Emacs Flatpak: gcc, cpp and gitare part of it:

sh-5.1$ which git
/usr/bin/git
sh-5.1$ which gcc
/usr/bin/gcc
sh-5.1$

(I'm guessing they're actually part of the underlying SDK -- Flatpaks
apparently are a kind of "layered system", where specific applications
can build upon the same support).

But Java and Ditaa aren't:

sh-5.1$ which java
which: no java in

Re: org-ditaa woes

2023-10-24 Thread Max Nikulin 

On 23/10/2023 18:18, Florin Boariu wrote:


sh-5.1$ flatpak-spawn --host toolbox run /usr/bin/ditaa /tmp/foo.txt 
-o /tmp/foo.png


thanks


I really _need_ to generically execute a command.


I hope, a couple of workarounds are still possible.

1. Get java command by adding bash -x (or /usr/bin/bash, or 
"/usr/bin/env bash")


flatpak-spawn --host toolbox run bash -x /usr/bin/ditaa \
/tmp/foo.txt -o /tmp/foo.png

- set `org-babel-ditaa-java-cmd' to something like
"flatpak-spawn --host toolbox run /usr/bin/java",
- set `org-ditaa-jar-path' to path to ditaa.jar reported by the command 
above,
- add other options to either `org-babel-header-args:ditaa' :java 
property or to `org-babel-ditaa-java-cmd'
- perhaps add /usr/bin/env JAVA_HOME=... and other required environment 
variables before java binary.



2.
- set `org-babel-ditaa-java-cmd' to
  "flatpak-spawn --host toolbox run /usr/bin/ditaa".
- set `org-ditaa-jar-option' to empty string.
- Call of `shell-quote-argument' makes it impossible to set 
`org-ditaa-jar-path' to empty string, so set the following variables to 
some harmless value, e.g. "-Dfile.encoding=UTF-8" (anything added 
through :java babel header argument):

  + `org-ditaa-jar-path'
  + `org-ditaa-eps-jar-path'


I agree that it should be possible to call ditaa executable directly. 
Perhaps it is not possible because for a long time ditaa.jar was a part 
of Org mode repository (there were a lot of messages against dropping of 
jar files from the repository). It seems, nobody is ready to take 
responsibility and to become maintainer of ob-ditaa.el while active 
users have no ability to install ditaa as a package, so they anyway have 
to download .jar from upstream.


I find it tedious to add "flatpak-spawn ..." to every tool used by 
Emacs. Who is the publisher of the flatpak? I would expect a directory 
with symlinks named ditaa, java, git, gcc, cpp, etc to a script line


#!/bin/sh
exec flatpak-spawn --host toolbox run /usr/bin/env "$0" "$@"

(or "$(basename "$0")")

mounted to flatpak runtime and added to $PATH. Perhaps another approach 
exist and it should be discussed with the packager and Emacs developers.

Re: org-ditaa woes

2023-10-23 Thread Florin Boariu 

I heard everybody referencing "org-plantuml" several times here :-)

I gave it a try, and, for reference, this is how my "org-plantuml" is
being set up in my case:


(org-babel-do-load-languages 'org-babel-load-languages '(
   [...]
   (plantuml . t)
   [...]
 ))

(setq org-plantuml-exec-mode 'plantuml)
(setq org-plantuml-executable-path "flatpak-spawn --host toolbox run 
/usr/bin/plantuml")



And with this as a document:


#+begin_src plantuml :file kmc3net.png
  bob -> alice: moo
#+end_src


it works as expected 路 (i.e. provides a [[file::kmc3net.png]] link,
which actually leads to a newly created file with the correct
contents).

Cheers,
F.

--
   "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 /.

Re: org-ditaa woes

2023-10-23 Thread Florin Boariu 

On Sat, Oct 21, 2023 at 10:50:08AM +0700, Max Nikulin wrote:


Does it work when executed from Emacs shell or eshell buffers?

Could you, please, provide complete sequence of commands to generate a 
graphics file from a ditaa source for a shell running in Emacs?


"M-x shell" and then:


sh-5.1$ echo -e "+-+\n| moo |\n+-+\n" > /tmp/foo.txt
sh-5.1$ cat /tmp/foo.txt 
+-+

| moo |
+-+

sh-5.1$ flatpak-spawn --host toolbox run /usr/bin/ditaa /tmp/foo.txt -o 
/tmp/foo.png

ditaa version 0.9, Copyright (C) 2004--2009  Efstathios (Stathis) Sideris

Running with options:
overwrite
Reading file: /tmp/foo.txt
Rendering to file: /tmp/foo.png
Done in 0sec
sh-5.1$ 


...gives pretty much the expected result, which is a PNG image of the
word "moo" embedded in a square. Is this what you hoped for?

Flatpack is a means to prevent accessing system files by applications 
that may have less degree of trust. I expect that a package should be 
carefully prepared to allow `man' and `info' access docs installed 
system-wide, files from /usr/share/doc should be available for 
doc-view, compiler toolchains should be available if Emacs is used for 
development. It sounds like rather broad permissions for isolated 
applications.


...I'm not an expert of Flatpak, but it is my understanding that it
uses something they call "portals" for defined access to your file
system. Apparently it's a bit more sphisticated than "just" broad
access.

For instance, once you have an application that requires to process a
file, you're presented with a dialog window by the OS (*not* by the
application) with which you can select your file. The file is then
opened for you, and your application only has the option to write to
that specific file -- and nowhere else. (Please don't fact-check me on
this, I really am just parroting concepts here... :-p)

This doesn't sound a lot like Emacs, and in fact I'm not sure how the
Emacs Flatpak works. Given that it's an "editor" designed to "edit"
everything, maybe it is indeed opening up most/all of the whole
host filesystem (?), has very little in the way of actual isolation
(??), and just uses Flatpak as a "package manager on steroids"
only to keep its own dependencies private (???).

But even this broad access to the host system isn't of any help to
me. This is because of the way the Fedora Silverblue distribution
works: the "bare linux" you boot into doesn't contain anything
beyond bare Wayland/Gnome desktop shell and essential system tools
(systemd, networking, DNS resolving, user management...). This is a
read-only ("immutable") image, like a perpetual, bare-bones "live
ISO" (courtesy of "libostree", https://ostreedev.github.io/ostree/ if
you're interested).

Any other applications -- gcc, python, additional libraries,
development tools, ditaa etc -- are being installed in a kind of
mutable container technology ("toolboxes", see
https://containertoolbx.org/ ). Those are pretty strongly isolated
from the host file system, and essentially only share the $HOME folder
and some state (/var, /proc, /dev, ...) with the host.

(This is a simplified view of things, but that's the gist of it.)

This means that even if the Emacs Flatpak was to give broad access to
the host, I still wouldn't be able to call "java -jar ...", simply
because the host system isn't meant to, and generally doesn't, even
have Java runtime to begin with, a ditaa.jar, or a /usr/bin/ditaa.
Those are meant to exist in toolboxes.

The command line above ("flatpak-spawn --host toolbox run [...]") is
designed to cross two namespacing boundaries:

  - "flatpak-spawn --host [...]" breaks out from the Flatpak,

  - "toolbox run [...]" then executes a command inside a toolbox
(e.g. "/usr/bin/ditaa").

The way they share data is worth some thought, but we incidentally get
lucky here: Emacs writes the code into "/tmp/...", which is shared
and accessible across all namespaces; and /usr/bin/ditaa read that,
and writes the PNG in the current project folder (in $HOME), which, in
this case, is also shared by emacs.

Hope this helps a bit to see the context of my request :-)

I really _need_ to generically execute a command.


Menu: Org → Documentation → Show version, Help → About Emacs
or M-x org-version


"9.6.6 (release_9.6.6 @ /app/share/emacs/29.1/lisp/org)"


M-x emacs-version.


"GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.16.0), of 2023-08-06"

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 /.

[TASK] Allow customizeable ditaa executable in ob-ditaa.el (was: org-ditaa woes)

2023-10-21 Thread Ihor Radchenko 
"Dr. Arne Babenhauserheide"  writes:

>>> In my current source I see [...]
>>>
>>> (use C-h v org-babel-ditaa-java-cmd to see the value of the java
>>> executable — you can then customize this to use a different command)
>>
>> As far as I understand that part of code it still kind-of assumes that
>> I'm using a command line of type "java -jar ditaa.jar ...", just with
>> more flexibility in choosing which "java" command I'm using, right?
>
> Yes, it does. ob-plantuml already migrated to allow a regular command,
> but ob-ditaa still only enables using the jar directly.
>
> That is something which would be nice to fix — and ob-plantuml should
> show the path forward.

+1
This is a relatively simple task.
One can indeed use ob-plantuml as a reference to extend ob-ditaa.
Patches welcome!

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

Re: org-ditaa woes

2023-10-21 Thread Dr. Arne Babenhauserheide 

Florin Boariu  writes:
> Replying to Arne's comment:
>
>> In my current source I see [...]
>>
>> (use C-h v org-babel-ditaa-java-cmd to see the value of the java
>> executable — you can then customize this to use a different command)
>
> As far as I understand that part of code it still kind-of assumes that
> I'm using a command line of type "java -jar ditaa.jar ...", just with
> more flexibility in choosing which "java" command I'm using, right?

Yes, it does. ob-plantuml already migrated to allow a regular command,
but ob-ditaa still only enables using the jar directly.

That is something which would be nice to fix — and ob-plantuml should
show the path forward.

> I've just tried setting org-babel-ditaa-java-cmd to "/usr/bin/ditaa",
> and org-ditaa-jar-option to "", but now the error is something like:
>
>> /usr/bin/ditaa   /orgfile/base/folder  \
>>  /tmp/babel-0YxwcE/ditaa-NyIQwH \
>>  /orgfile/base/folder/network.png
>
> where "/orgfile/base/folder" is the dirname of the full path of my
> .org file (e.g. something like /orgfile/base/folder/file.org).
>
> So org-ditaa apparently somewhere still tries to set a work directory
> (or so?) after the org-ditaa-jar-option part. I'm not exactly sure
> which code version the current Emacs Flatpak has, and I don't know how
> to look (I'm not *that* much of a Flatpak nerd :-p ) But if I had to
> bet, I'd assume it's a fairly recent one.

If you do the C-h v org-ditaa-jar-option command, you should normally
have a link to ob-ditaa.el in your help buffer. You can click that to
get the source.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: org-ditaa woes

2023-10-20 Thread Max Nikulin 

On 21/10/2023 04:39, Florin Boariu wrote:

   $ flatpak-spawn --host toolbox run /usr/bin/ditaa --help


Does it work when executed from Emacs shell or eshell buffers?

Could you, please, provide complete sequence of commands to generate a 
graphics file from a ditaa source for a shell running in Emacs?


Flatpack is a means to prevent accessing system files by applications 
that may have less degree of trust. I expect that a package should be 
carefully prepared to allow `man' and `info' access docs installed 
system-wide, files from /usr/share/doc should be available for doc-view, 
compiler toolchains should be available if Emacs is used for 
development. It sounds like rather broad permissions for isolated 
applications.



I'm not exactly sure
which code version the current Emacs Flatpak has, and I don't know how
to look


Menu: Org → Documentation → Show version, Help → About Emacs
or M-x org-version, M-x emacs-version.


PS: I'm not sure how to read this in gmane.
[…] Apparently I need to do it via
NNTP?...


Yes, add news.gmane.io news server and subscribe to gmane.emacs.orgmode. 
You may send replies using your regular SMTP mail account.

Re: org-ditaa woes

2023-10-20 Thread Florin Boariu 


Can you give us the command-line you would like to use?
That would help to fix the problem you are confronting.


A "regular" one would be just simply "/usr/bin/ditaa":

---
  $ ditaa --help
  usage: java -jar ditaa.jar  [OUTFILE] [-A] [-b ] [-d]  
 [-E] [-e ] [-h] [--help] [-o] [-r] [-S] [-s ] [-T]

 [-t ] [-v] [-W]
   -A,--no-antialias  Turns anti-aliasing off.
  ...
---

For instance "ditaa diagram.txt -o diagam.png" would do exactly what
one would expect: translate diagram.txt into the coresponding image.

A more fancy one when using Flatpaks and container toolboxes are
involved would be "flatpak-spawn". E.g. this is what it takes from
within the org.gnu.emacs Flatpak sandbox to run "ditaa" in a Toolbox
container (different sandbox):

---
  $ flatpak-spawn --host toolbox run /usr/bin/ditaa --help
  usage: java -jar ditaa.jar  [OUTFILE] [-A] [-b ] [-d]
 [-E] [-e ] [-h] [--help] [-o] [-r] [-S] [-s ] [-T]
 [-t ] [-v] [-W]
   -A,--no-antialias  Turns anti-aliasing off.
  ...
---

(Note that the self-reported message says "usage: java -jar
ditaa.jar...", but this really just behaves like a regular command
line application.)

Replying to Arne's comment:


In my current source I see [...]

(use C-h v org-babel-ditaa-java-cmd to see the value of the java
executable — you can then customize this to use a different command)


As far as I understand that part of code it still kind-of assumes that
I'm using a command line of type "java -jar ditaa.jar ...", just with
more flexibility in choosing which "java" command I'm using, right?

I've just tried setting org-babel-ditaa-java-cmd to "/usr/bin/ditaa",
and org-ditaa-jar-option to "", but now the error is something like:


/usr/bin/ditaa   /orgfile/base/folder  \
 /tmp/babel-0YxwcE/ditaa-NyIQwH \
 /orgfile/base/folder/network.png


where "/orgfile/base/folder" is the dirname of the full path of my
.org file (e.g. something like /orgfile/base/folder/file.org).

So org-ditaa apparently somewhere still tries to set a work directory
(or so?) after the org-ditaa-jar-option part. I'm not exactly sure
which code version the current Emacs Flatpak has, and I don't know how
to look (I'm not *that* much of a Flatpak nerd :-p ) But if I had to
bet, I'd assume it's a fairly recent one.

Cheers,
Florin.

PS: I'm not sure how to read this in gmane. I went to gmane.io, but
all I see is a green text and two links -- a kind-of blog entry with
gmane's history, and an admin interface. None of those looks like I'd
be able to browse the mailing list. Apparently I need to do it via
NNTP?...

--
   "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 /.

Re: org-ditaa woes

2023-10-20 Thread Leo Butler 
On Fri, Oct 20 2023, "Dr. Arne Babenhauserheide"  wrote:

> Leo Butler  writes:
>
 [...]
(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)))
 [...]
>
> From the commit, this is an ancient version of ob-ditaa (11 years ago).
>
> In my current source I see
>
>(cmd (concat org-babel-ditaa-java-cmd
> " " 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)
> " " (if pdf-cmd
> eps-file
>   (org-babel-process-file-name out-file)
>
> (use C-h v org-babel-ditaa-java-cmd to see the value of the java
> executable — you can then customize this to use a different command)
>
> Going forward we may want to adjust ob-ditaa to allow for an executable
> like ob-plantuml does it.
>
> Best wishes,
> Arne

Arne,
Thank you for the correction, you are right about the vintage (and
about the suggestion vis-a-vis ob-plantuml, imo).

Leo

Re: org-ditaa woes

2023-10-20 Thread Dr. Arne Babenhauserheide 

Leo Butler  writes:

>>> [...]
>>>(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)))
>>> [...]

From the commit, this is an ancient version of ob-ditaa (11 years ago).

In my current source I see

 (cmd (concat org-babel-ditaa-java-cmd
  " " 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)
  " " (if pdf-cmd
  eps-file
(org-babel-process-file-name out-file)

(use C-h v org-babel-ditaa-java-cmd to see the value of the java
executable — you can then customize this to use a different command)

Going forward we may want to adjust ob-ditaa to allow for an executable
like ob-plantuml does it.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: org-ditaa woes

2023-10-20 Thread Leo Butler 
Hello Florin,

On Thu, Oct 19 2023, Florin Boariu  wrote:

> 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...)

You can read (and post to?) this email list on gmane.

> 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 think you have identified a bug in ob-ditaa.el. Your request is
perfectly reasonable and that CMD should not have such hard-coded
constants in it, imo.

> 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.

Can you give us the command-line you would like to use?
That would help to fix the problem you are confronting.

>
> 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? :-)

The deeper reason is likely that ob-ditaa worked for whomever wrote it,
and users have either accepted its limitations (if noted), worked around
them, or gave up.

>
> 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?

You could use ob-shell, but it would be preferable to fix the bug you
have identified.

>
> Thanks & cheers,
> Florin.

Leo

org-ditaa woes

2023-10-20 Thread Florin Boariu 

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