Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Greetings Bastien.

Bastien  writes:

>> Bastien, ob-asymptote is still a part of org-contrib [1].  Should we
>> just go ahead and change the maintainer now?
>>
>> [1] https://git.sr.ht/~bzg/org-contrib/tree/master/item/lisp/ob-asymptote.el
>
> Yes, done.  Thanks Jarmo for taking over the maintenance!
>
> Feel free to package ob-asymptote.el as a GNU ELPA package so that it
> gets more users and let me know when this is done so that I can remove
> it from org-contrib.

Will do so.

All the best,

Jarmo

Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Greetings Ihor.

Ihor Radchenko  writes:

> Jarmo, did you hear anything from Luc? There was no action in
> ob-asymptote for over a year. If the current maintainer does not reply
> to email requests related to ob-asymptote, I'd rather transfer to
> maintenance to someone more active.

Nope. I sent him another email some weeks ago, no response.

Let me know how we will proceed.

All the best,

Jarmo

Re: Haskell code blocks

[Jarmo Hurri]

Greetings Thomas.

"Thomas S. Dye"  writes:

> I'm struggling to write a minimal ob-doc-haskell.org for Worg.
>
> The obligatory Hello World! example yields bad results.
>
> #+name: haskell-hello-world
> #+begin_src haskell 
>
> main :: IO () 
> main = putStrLn  "Hello, World!"
> main
> #+end_src
>
> #+RESULTS: haskell-hello-world
> : Prelude> Hello, World!

The good ole obligatory part is fulfilled by including ":session none":

 #+name: haskell-hello-world
 #+begin_src haskell :session none
   main :: IO () 
   main = putStrLn  "Hello, World!"
   main
 #+end_src

 #+RESULTS: haskell-hello-world
 : Hello, World!

All the best,

Jarmo

Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Greetings Bastien.

Bastien  writes:

> Did you manage to get feedback from Luc, maintainer of ob-asymptote.el
> on org-contrib to decide who will maintain it, where to host it?  It
> seems like having ob-asymptote.el on GNU ELPA would be very good.

Not yet, but after my recent return from the land of the dead
(a.k.a. work), I just threw another email at Luc. I will let you know.

All the best,

Jarmo

Re: Volunteering to maintain ob-processing.el

[Jarmo Hurri]

Greetings Bastien.

>> I see that ob-processing.el has currently no maintainer. I volunteer.
>
> Thanks!  I added you as the maintainer in the main branch.

Excellent. I will get onto it.

All the best,

Jarmo

Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Greetings Bastien!

Bastien  writes:

>> I hereby volunteer to maintain ob-asymptote.el. This file has been
>> moved to org-contrib, but I would like it to be brought back into Org
>> itself.
>
> I added Luc (cc'ed) as the maintainer of ob-asymptote.el a while ago:
>
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=27621a5b
>
> Perhaps you can discuss with him to decide whether you both want to
> maintain this file or just one of you?

I do not wish to "steal" ob-asymptote.el from anyone; if Luc is happy
being the maintainer, this is fine by me.

In fact, perhaps it would be best at this point if Luc would maintain
ob-asymptote.el and I would create a good set of examples in Worg:

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

If ob-asymptote.el is moved out of org-contrib, where whould this page
reside?

> As maintainer(s) or ob-asymptote.el, the first step should probably be
> to package it for GNU ELPA: both you and Luc have signed the FSF
> copyright assignment, so there is no blocker for joining GNU ELPA.
> Then we can move it out of org-contrib, which just serves as a
> transitory repository.

This is an excellent idea. I would certainly want ob-asymptote.el out of
org-contrib, since the advertisement for org-contrib almost guarantees
that the files are not maintained. :-)

> For now, I'd rather be conservative with what is added to Org's core:
> GNU ELPA is reachable enough for "niche" features.  If/when Asymptote
> gets more support within Emacs core, we can move ob-asymptote.el in
> Org's core back again.
>
> Would that be okay for you (both)?

This is fine by me. I can start marketing to increase level of interest.

All the best,

Jarmo

Re: The fate of ob-asymptote.el

[Jarmo Hurri]

Hello Ihor.

Ihor Radchenko  writes:

> Well. You convinced me. If Asymptote has very stable syntax and major
> features, it probably makes more sense to maintain it within Org or
> within Org community.

If Bastien shows the green light, I am looking forward to giving back
something to the community: maintanance and a good set of illustrative
examples on worg. For the past 2 years I have just been utilizing what
you guys have been doing, in a state of haze, for obvious reasons.

>> - I embrace a (any) maintained feature which extends the
>> applicability of Org without compromising "the core." I have had
>> great moments noticing that Org already supports something new I
>> need.
>
> I agree that it is nice, but we cannot, unfortunately support all the
> programming languages out there. As long a some specific language has
> a maintainer, things are fine, but in long term it is only reliable to
> support popular ones + possibly GNU projects (as Org is a part of GNU,
> and it is kind of obligation).

Makes sense. As long as there is a maintainer, a more exotic language
can be supported. Perhaps my contribution will increase the popularity
of Asymptote within the Org community and therefore the probability of
long term survival of ob-asymptote.el.

> As long as there is a person maintaining ob-asymptote, things should
> be fine. Especially if there is a good test coverage and WORG
> documentation.

I will be in standby mode until Bastien tells me what happens next.

All the best,

Jarmo

Re: The fate of ob-asymptote.el

[Jarmo Hurri]

Hello again.

Ihor Radchenko  writes:

> Jarmo Hurri  writes:
>> As a result, changes in Org are much more likely to affect
>> ob-asymptote.el than changes in Asymptote. I think basic software
>> development rules of thumb suggest that ob-asymptote.el should then
>> be bundled with Org.
>
> From my point of view ob-asymptote.el is as bare bones as babel
> library can be. It does not use any fancy Org babel features like
> sessions, error display of converting the output to various :results
> output options.
>
> In contrast, it does a lot of work trying to convert Elisp types to
> Asymptote in `org-babel-asymptote-var-to-asymptote`.

Fair point. Then again, the involved datatypes of Asymptote are,
practically, immutable.

I can not resist pointing out that we are having this discussion because
of changes in Org, not because of changes in Asymptote. I consider Org
much more volatile than Asymptote.

But I might be digressing. A bit of a summary:

- I embrace a (any) maintained feature which extends the applicability
  of Org without compromising "the core." I have had great moments
  noticing that Org already supports something new I need.

- Asymptote is brilliant. :-) I hope I can provide connectivity to Org
  for current and future users. When I shrivel away, this support might
  get buried next to me.

- Org contrib basically advertises itself as unmaintained. While that
  may change, and there is in fact a request to help maintain the
  add-ons on the github page, I am pessimistic. I would not install it,
  so I doubt others would either.

- I see Org as the logical place for ob-asymptote.el. If this is
  rejected, I may try inclusion into Asymptote if it is not an uphill
  battle.

> From my point of view, any kind of new functionality in
> ob-asymptote.el requires a deep knowledge about the Asymptote
> programming - the knowledge most of the Org devs lack. At the same
> time, changes in Org babel core functionality are unlikely to cause
> any issues in ob-asymptote - we try our best to keep backwards
> compatibility with third-party babel packages anyway.

Does this suggest that, from the point of view of Org, the risk of
supporting ob-asymptote.el is minimal?

All the best,

Jarmo

Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Greetings again, Ihor.

Ihor Radchenko  writes:

> After removing org-contrib over a year ago, your email is the first
> issue raised regarding ob-asymptote removal.

This is an interesting observation.

I have been using Asymptote with Org all the time, with the latest Org
from ELPA. Only when my distribution upgraded Emacs to 28.1 did errors
about ob-asymptote.el start popping up. So ob-asymptote.el must have
crept in from some directory this entire time.

I am not claming there are (lots of) ob-asymptote.el users out there,
just pointing out why this discussion takes place one year after the
fact.

Will return to other messages later, got to run now (literally).

All the best,

Jarmo

Re: The fate of ob-asymptote.el

[Jarmo Hurri]

Greetings Ihor.

Ihor Radchenko  writes:

> Jarmo Hurri  writes:
>
>>> Then, would it make more sense to include ob-asymptote.el into the
>>> asymptote distribution?
>>
>> I do not think this is a good idea:
>>
>> - I am not involved in the development of asymptote, so this solution
>>   would put maintenance of ob-asymptote.el beyond my reach.
>
> AFAIK, it is developed publicly. Anyone can open a pull request or
> post on their forum.

It might be possible, but certainly not as straightforward as working
with Org.

> The advantage of maintaining ob-asymptote.el in the main asymptote
> repo is that people who are intimately familiar with the asymptote
> features can directly contribute and enhance the Org
> integration. Moreover, distributing together with the asymptote means
> no headache with back-compatibility issues.
>
> Maintaining on Org side will have an advantage of using the latest
> additions to Org babel features.
>
> I feel like it is more important to make use of the asymptote features
> if its devs are going to be interested. Of course, IMHO.

I have a very bad feeling about tying ob-asymptote.el with Asymptote,
and I am trying to put my finger on this feeling. I think the problem is
this one.

ob-asymptote.el is coupled very loosely with Asymptote. Basically the
only thing ob-asymptote.el requires from Asymptote is the ability to
call the executable with some established parameters.

Then again, ob-asymptote.el is coupled much more tightly with Org. It
uses many more properties of Org (Babel) than of the Asymptote
program.

As a result, changes in Org are much more likely to affect
ob-asymptote.el than changes in Asymptote. I think basic software
development rules of thumb suggest that ob-asymptote.el should then be
bundled with Org.

All the best,

Jarmo

Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Ihor Radchenko  writes:

> Jarmo Hurri  writes:
>>> TBH, this is the first time I'm hearing about it.  I've looked it
>>> up, and indeed it seems to be useful.
>>
>> For some reason, even people who would certainly benefit from
>> Asymptote often have not heard of it. The developers do not really
>> advertise. Asymptote is amazingly powerful and sophisticated.
>
> Then, it would help to have more practical examples compared to what
> we have in
> https://www.orgmode.org/worg/org-contrib/babel/languages/ob-doc-asymptote.html

Absolutely. I have plenty of examples from the domains of math and
computer science.

>>> That said, shouldn't this be in org-contrib?  Too many features in a
>>> tool - featurism - may be distracting, in the sense that you focus
>>> more on your tool than work at hand.
>>
>> I do not understand this. Why would supporting a professional-level
>> graphics programming language be distracting someone from their work
>> when using Org?
>
> That a common minimalist argument. Some people dislike the fact that
> software includes features they do not personally use. Similar
> arguments are often raised regarding, for example, games shipped with
> Emacs.

I do not see Org as a "minimalist" system. I see it as glue.

I think one of the great powers of Org mode is its capability to act
together with various systems, including LaTeX and a host of programming
languages. I would never imagine that Org would only support the tools I
use, but I expect to be positively surprised by the fact that Org will
support, out of the box, something that I am not using now but will be
using in the future.

> I disagree in this particular case. Having ob-asymptote.el is not a
> featurism - I would not expect people to play around a full new
> programming language just because ob-language.el is in Org. The
> barrier of entry is too high to make it destructing.

I am not sure I can interpret your text correctly. But if you are saying
that builtin support for Asymptote will not lower the threshold of its
use among Org users, I would ask the following questions:
- How many Org users are already capable of programming?
- How many Org users prefer code-based representations to other forms?

All the best,

Jarmo

Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Hello Munyoki.

Munyoki Kilyungi  writes:

>> I do not understand this. Why would supporting a professional-level
>> graphics programming language be distracting someone from their work
>> when using Org?
>
> I'm not _against_ supporting a proffesional-level graphics PL.  What
> I'm trying to say is that having it installed should be a choice made
> by the end-user.

I think someone already mentioned that having ob-asymptote.el within Org
does not require the end users to install anything.

> I reckon I'll give this is a shot this coming weekend and see how this
> goes.  Is this:
> 
> sufficient to get me started?

It is sufficient, but I am not sure whether those examples are a good
way to start.

If you want to get acquainted with Asymptote, I suggest that after
setting it up you take a minimal example like the following

#+begin_src asymptote :file result-figure.pdf
size (8cm, 0);
#+end_src

and then use various sources such as the ones below to explore and learn:

- Charles Staats' Asymptote tutorial

  https://asymptote.sourceforge.io/asymptote_tutorial.pdf

- Asymptote manual

  https://asymptote.sourceforge.io/asymptote.pdf

- Art of Problem Solving forums, which use Asymptote as their built-in
  graphics language, e.g.

  https://artofproblemsolving.com/community/c5h2782914_another_hexagon_problem

  (click on a diagram to see the corresponding Asymptote code).

  see also

  https://artofproblemsolving.com/wiki/index.php/Asymptote:_Getting_Started

All the best,

Jarmo

Volunteering to maintain ob-processing.el

[Jarmo Hurri]

Greetings.

I see that ob-processing.el has currently no maintainer. I volunteer.

All the best,

Jarmo

Re: Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Greetings Munyoki.

Munyoki Kilyungi  writes:

> Hi Jarmo!
>
> Jarmo Hurri  anaandika:
>
>> I hereby volunteer to maintain ob-asymptote.el.
>
> Nice!
>
>> This file has been moved
>> to org-contrib, but I would like it to be brought back into Org itself.
>>
>> I strongly feel that Asymptote is way too valuable as a scientific tool
>> to be dropped out of Org.

> Isn't this debatable?  

Yes, that is a good reason to be involved in these discussions.

> TBH, this is the first time I'm hearing about it.  I've looked it up,
> and indeed it seems to be useful.  

For some reason, even people who would certainly benefit from Asymptote
often have not heard of it. The developers do not really
advertise. Asymptote is amazingly powerful and sophisticated.

> That said, shouldn't this be in org-contrib?  Too many features in a
> tool - featurism - may be distracting, in the sense that you focus
> more on your tool than work at hand.  

I do not understand this. Why would supporting a professional-level
graphics programming language be distracting someone from their work
when using Org?

> And that said, to work around this, I reckon that's why (?)  we have
> org-contrib.  You - the end user - install what you want/need. 

Yes, but whenever we split up support, we raise the threshold for the
use of a combination of tools, in this case Org and Asymptote.

Org is a very powerful publication tool. Does it not make complete sense
to include support for a tool for creating professional-quality
publication graphics?

All the best,

Jarmo

Re: The fate of ob-asymptote.el

[Jarmo Hurri]

Hello Ihor.

Ihor Radchenko  writes:

> Max Nikulin  writes:
>
>>> Is major-mode for editing asymptote code available easily?
>>> I was unable to find anything relevant in ELPA and non-GNU ELPA.
>>
>> I am not an asymptote user, but the following suggests that it may be
>> installed with asymptote package
>>
>> https://packages.debian.org/file:asy-mode.el
>
> Confirm. I also do see an "emacs" use-flag in asymptote Gentoo package.

That seems to also be the case for Fedora:

sh-5.1$ dnf provides "*site-lisp/asymptote/asy-mode.el"
symptote-2.81-1.fc36.x86_64 : Descriptive vector graphics language
Repo: @System
Matched from:
Other   : *site-lisp/asymptote/asy-mode.el

> Then, would it make more sense to include ob-asymptote.el into the
> asymptote distribution?

I do not think this is a good idea:

- I am not involved in the development of asymptote, so this solution
  would put maintenance of ob-asymptote.el beyond my reach.

- I have no idea whether developers of Asymptote have any interest in
  Org.

- Comparing to another language: what is the situation e.g. with
  Haskell? We have ob-haskell.el (thanks to Lawrence Bottorff). In my
  distro at least, I have Haskell mode installed separately. Should we
  then move ob-haskell.el into the package supplying Haskell mode?

- Somehow I also think that the proposed solution would be close to the
  idea of including ob-C.el into a C compiler distribution.

All the best,

Jarmo

Re: The fate of ob-asymptote.el

[Jarmo Hurri]

Hello Nick!

Nick Dokos  writes:

> Jarmo Hurri  writes:
>
>> ...
>>
>> I would like ob-asymptote.el to be brought back. If there is something I
>> can do to help, I will be glad to do so.
>>
> All you have to do is volunteer to maintain it. Let Bastien know: he
> will assign you the maintenance of the file and all the asymptote
> users will owe you a debt of gratitude.

Thanks!

I have just posted another message into this group for this purpose.

All the best,

Jarmo

Volunteering to maintain ob-asymptote.el within Org

[Jarmo Hurri]

Greetings.

I hereby volunteer to maintain ob-asymptote.el. This file has been moved
to org-contrib, but I would like it to be brought back into Org itself.

I strongly feel that Asymptote is way too valuable as a scientific tool
to be dropped out of Org.

All the best,

Jarmo

The fate of ob-asymptote.el

[Jarmo Hurri]

Greetings.

Summary: I vote, very late, for the inclusion of ob-asymptote.el into
Org. In my opinion, Asymptote is far too valuable a tool to be excluded
by default.

Long version:

Either me or my system have been sleeping for quite a while, because
just today I woke up to the fact that ob-asymptote.el has been moved out
of Org and into org-contrib. According to org-contrib, this means that

Files in this repository receive little if no maintainance and there is
no guarantee that they are compatible with the Org stable version.

Not only is this a poor situation for me personally, but I also think it
is a bad decision for Org. I have been using the combination of Org and
Asymptote for all my work stuff for a long time now. The combo is simply
_superior_. I do not need to talk about Org, and will focus on Asymptote
only.

Asymptote is a _brilliant__ tool for drawing all sorts of (scientific)
diagrams, be those 2D or 3D (click on menu on left to view different
galleries):

https://asymptote.sourceforge.io/gallery/

Asymptote has been a stable programming language for quite a while:

https://asymptote.sourceforge.io/

It is being actively maintained and upgraded.

If ob-asymptote.el is kept external to Org, future users will have a
much higher threshold to use this combination.

I would like ob-asymptote.el to be brought back. If there is something I
can do to help, I will be glad to do so.

All the best,

Jarmo

Re: 9.5: coping with loss of ditaa.jar

[Jarmo Hurri]

Greetings Tim.

Tim Cross  writes:

> I think you missed one obvious solution - donwload the jar file from
> the ditaa project homepage on sourceforge.

> Another alternative which I just found is the ditaa version on github,
> which has SVG support. See https://github.com/stathissideris/ditaa. If
> you click on the 'release' link on the right, there is the most recent
> release, which includes a link to a standalone ditaa.jar file.

Ok, so at least two different standalone versions seem to be available:

1. via "project page" on sourceforge; looking inside the downloaded zip,
   this seems to be version 0.9

2. via developer github page, version 0.11.

On the github page there is a discussion indicating that a clojure
version will _not_ be forthcoming after all. The author also states that
(s)he is no longer interested in maintaining ditaa:

https://github.com/stathissideris/ditaa/issues/69

> I don't think you need to be paranoid about downloading the jar file
> from the project homepage - either you trust the code or you don't. If
> you don't trust the code, then even compiling it yourself adds no
> additional protection.

Trying to avoid binaries from "weird" sources probably just adds a sense
of false security. Sometimes false security is the best you can get.

Have fun and stay safe,

Jarmo

Re: 9.5: coping with loss of ditaa.jar

[Jarmo Hurri]

Howdy.

"Thomas S. Dye"  writes:

>> 2. Use the program "ditaa" (not ditaa.jar) that comes with your
>>operating system. This _may_ work, but I have not been ableto
>> misuse
>>the settings in ob-ditaa widely enough yet to create aworking
>>solution.
>
> This worked for me on Ubuntu 20.04, if it is helpful.
>
> sudo apt-get install ditaa
>
> Then set org-ditaa-jar-path to "/usr/bin/ditaa".

I get an error:

Error: Invalid or corrupt jarfile /usr/bin/ditaa

What I also tried to do is to change org-babel-ditaa-java-cmd to "ditaa"
and modify other parameters such as org-ditaa-jar-option
accordingly. But no cigar so far.

Have fun and stay safe,

Jarmo

Re: 9.5: coping with loss of ditaa.jar

[Jarmo Hurri]

Colin Baxter   writes:

>>>>>> Jarmo Hurri  writes:
>
>
>> 3. Copy ditaa.jar from previous version of org. Works in the short
>> run, but I do not think we want to advocate this: "We took ditaa.jar
>> out of org, so you will want to download an earlier version of org to
>> make ditaa work."
>
> Not true. I use Org mode version 9.5 (release_9.5-91-gf5faff) with a
> previous org-mode ditaa.jar and have no issues.

Sorry for my confusing language: I meant "you need to download an
earlier version of org _and take ditaa.jar from it_ to make ditaa work."

So I agree: no issues with this approach, but I do not think this is
what we would like users to have to do.

Have fun and stay safe,

Jarmo

Re: 9.5: coping with loss of ditaa.jar

[Jarmo Hurri]

Greetings.

Let me collect the suggested responses with their merits and potential
issues.

1. Use ditaa.jar that comes with your operating system. Perfect if this
   works. Seems to work e.g. in Debian, does not seem to work with
   Fedora. Perhaps because one is a standalone library and the other one
   is not. Could also be a version number issue.

2. Use the program "ditaa" (not ditaa.jar) that comes with your
   operating system. This _may_ work, but I have not been able to misuse
   the settings in ob-ditaa widely enough yet to create a working
   solution.

3. Copy ditaa.jar from previous version of org. Works in the short run,
   but I do not think we want to advocate this: "We took ditaa.jar out
   of org, so you will want to download an earlier version of org to
   make ditaa work."

4. Use precompiled binary ditaa.jar from some site. Will probably work,
   but me and some other paranoids try to avoid using binaries from
   sources which we do not consider reliable.

5. Compile ditaa.jar yourself. At least for me, does not work at the
   moment.

To summarize: on Fedora, no working long-term solution so far.

Have fun and stay safe,

Jarmo

9.5: coping with loss of ditaa.jar

[Jarmo Hurri]

Greetings.

I use ditaa with org on a regular basis. Now that ditaa.jar is out of
org 9.5, I need to cope with the situtation.

I see two options, and neither was successful today. This is sort of
what I was afraid of when I voted for keeping ditaa bundled with org.

1. I am running Fedora 34, where ditaa is available as a
   package. However, just pointing org-ditaa-jar-path to the correct
   location /usr/share/java/ditaa.jar is not sufficient, because doing
   so leads to errors when trying to execute a ditaa babel block:

   Error: Unable to initialize main class 
org.stathissideris.ascii2image.core.CommandLineConverter
   Caused by: java.lang.NoClassDefFoundError: 
org/apache/commons/cli/ParseException

   Taking a look at what the system binary "ditaa" does, I found the
   following shell script:

   # -
   #!/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 "$@"
   # -

   Has anyone successfully fed all these parameters to ob-ditaa?

2. Ditaa is available via github at
   https://github.com/stathissideris/ditaa

   The developer section points to building with some clojure build
   system lein, which is not available in my system, and in Fedora,
   running

   dnf list available '*lein*'

   gives me nothing useful.

   There are, however, ant build files available in ditaa repo under
   build. Then again, running ant with any parameters I could think of
   leads to the error

   BUILD FAILED
   /home/jarmo/src/ditaa/build/build.xml:6: The following error occurred while 
executing this line:
   /home/jarmo/src/ditaa/build/release.xml:67: /home/jarmo/src/ditaa/lib does 
not exist.

   Has anyone succesfully compiled ditaa for use with org?

Have fun and stay safe.

Jarmo

Re: Stable 9.5: invalid function (date date)

[Jarmo Hurri]

Ihor Radchenko  writes:

> Jarmo Hurri  writes:
>
>> Greetings.
>>
>> I just installed (stable) 9.5. from GNU ELPA, and tried to see what my
>> agenda for today looks like. The agenda is empty, and I got error
>>
>> Debugger entered--Lisp error: (invalid-function (date date))
>>
>> with backtrace
>>
>>   (date date)()
>>   org-agenda-get-day-entries("/home/jarmo/projects/gtd/faq.org" (10
>> 2 2021) :deadline :scheduled :timestamp :sexp)
>
> Looks like garbled installation.  Can you try to re-install Org?

Hello Ihor.

This morning the install instructions on orgmode.org had changed from
yesterday: they now pointed to the manual, which contains the text

Important: You need to do this in a session where no ‘.org’ file has
been visited, i.e., where no Org built-in function have been
loaded. Otherwise autoload Org functions will mess up the installation.

I reinstalled from "emacs -q", and my error disappeared. So thank you
very much.

Have fun and stay safe.

Jarmo

Stable 9.5: invalid function (date date)

[Jarmo Hurri]

Greetings.

I just installed (stable) 9.5. from GNU ELPA, and tried to see what my
agenda for today looks like. The agenda is empty, and I got error

Debugger entered--Lisp error: (invalid-function (date date))

with backtrace

  (date date)()
  org-agenda-get-day-entries("/home/jarmo/projects/gtd/faq.org" (10 2 2021) 
:deadline :scheduled :timestamp :sexp)
  apply(org-agenda-get-day-entries "/home/jarmo/projects/gtd/faq.org" (10 2 
2021) (:deadline :scheduled :timestamp :sexp))
  org-agenda-list(nil)
  funcall-interactively(org-agenda-list nil)
  call-interactively(org-agenda-list)
  org-agenda(nil)
  funcall-interactively(org-agenda nil)
  call-interactively(org-agenda nil nil)
  command-execute(org-agenda)

Any ideas?

I am running

(emacs-version)
"GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.30, cairo 
version 1.17.4)
 of 2021-08-07"

in

Linux fedora 5.14.9-200.fc34.x86_64 #1 SMP Thu Sep 30 11:55:35 UTC 2021 x86_64 
x86_64 x86_64 GNU/Linux

Have fun and stay safe.

Jarmo

Re: Release 9.5

[Jarmo Hurri]

Bastien  writes:

> Org 9.5 is out, available from GNU ELPA.

Exciting!

I just ran 'git pull' and got a warning and an error:

warning: redirecting to https://git.savannah.gnu.org/git/emacs/org-mode.git/
Your configuration specifies to merge with the ref 'refs/heads/maint'
from the remote, but no such ref was fetched.

Do I need to start a new clone from scratch, or is there a fix for this?

(I honestly have _no recollection_ of what changes I have made, and what
changes need to be made, to the cloned repository locally in order for
'make' to run successfully.)

Have fun and stay safe.

Jarmo

Re: Org table: numeric locale

[Jarmo Hurri]

Maxim Nikulin  writes:

> On 28/08/2021 14:07, Jarmo Hurri wrote:
>> I wonder if it is possible to get org table formulas to respect
>> numeric locale.
>
> Even to add some functions to Emacs that respect numeric locales, it
> is necessary to use e.g. dynamic modules

>> Emacs documentation says that Emacs uses the value of LC_NUMERIC:
>> https://www.gnu.org/software/emacs/manual/html_node/emacs/General-Variables.html
>
> It is a confusing statement, see:
> - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29645
>   #29645 Feature Request: Locale aware formatting
>   Date: Sun, 10 Dec 2017 15:05:02 UTC
> - https://lists.gnu.org/archive/html/emacs-devel/2021-06/msg00327.html
>   https://lists.gnu.org/archive/html/emacs-devel/2021-06/msg00139.html
>
> The state of numeric locales in Emacs is a little worse than just
> unsupported. Mostly "C" is forced for LC_NUMERIC, so e.g. grouping is
> not used.

I see. I am surprised by the disparity between documentation and
reality, given the quality I have learned to associate with emacs.

Thank you very much,

Jarmo

Org table: numeric locale

[Jarmo Hurri]

Greetings.

I wonder if it is possible to get org table formulas to respect numeric
locale.

Emacs documentation says that Emacs uses the value of LC_NUMERIC:

https://www.gnu.org/software/emacs/manual/html_node/emacs/General-Variables.html

However, even though I have a value of LC_NUMERIC which specifies comma
as a decimal separator, I get dot as a decimal separator when formatting
a floating point value in both elisp and in org table formula. So yes, I
am aware that the source of the issue is likely to be in Emacs, but I
only need a solution for org only.

The example at the end of this message tries to illustrate all aspects:
what my environment variables are, what Emacs sees and does, what org
does, and how to force locale in another language (C++).

Have fun and stay safe,

Jarmo

# -
* My relevant locale variables in shell
  #+begin_src sh
echo "LANG: ${LANG}"
echo "LC_ALL: ${LC_ALL}"
echo "LC_NUMERIC: ${LC_NUMERIC}"
  #+end_src

  #+RESULTS:
  | LANG:   | en_GB.UTF-8 |
  | LC_ALL: | |
  | LC_NUMERIC: | fi_FI.UTF-8 |

* What emacs sees and does
  Emacs uses dot, not comma, as decimal separator.
  #+begin_src elisp
(let ((env (mapconcat 'getenv (list "LANG" "LC_ALL" "LC_NUMERIC") " "))
  (str (format "%.2f" (/ 1.0 3
  (concat env "\n" str "\n" (emacs-version)))
  #+end_src

  #+RESULTS:
  : en_GB.UTF-8  fi_FI.UTF-8
  : 0.33
  : GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.30, 
cairo version 1.17.4)
  :  of 2021-08-07

* What Org table does
  Org table also uses dot, not comma, as decimal separator.
  | 0.33 |
  #+TBLFM: @1$1=1.0/3;%.2f

* C++ version (for comparison)
  #+begin_src C++ :results raw
#include 
#include 
#include 

int main (int argc, char* argv[])
{
// I have to set locale, it is not obtained automatically from
// shell environment
setlocale (LC_NUMERIC, getenv ("LC_NUMERIC"));

printf ("%.2f", 1.0 / 3);
exit (0);
}
  #+end_src

  #+RESULTS:
  0,33
# -

Re: Org table: emphasizing calculated cell

[Jarmo Hurri]

Greetings Norwid.

Norwid Behrnd  writes:

> Let's use your idea to use /multiple table formulae/.  Contrasting to
> your attempt, I don't mind to go the extra mile and to run a cheap
> computation twice for a result already in hand.  As a MWE 
>
> ```
> | quantity  |  value |
> | A |  1 |
> | B |  3 |
> | ratio A/B | *0.33* |
> | ratio + 1 |   1.33 |
>
> #+TBLFM: @4$2 = @2/@3; *%.2f* :: @5$2 = @2/@3 + 1; %.2f
> ```

Thanks, that is indeed a working approach. As you suspected, I would go
an extra mile or ten to avoid repeating formulae. ;)

Have fun and stay safe,

Jarmo

Re: Org table: emphasizing calculated cell

[Jarmo Hurri]

Nick Dokos  writes:

> Jarmo Hurri  writes:
>> This solution seems to change the contents of a cell, not only its
>> formatting. So the following, where I try to increase the value of "C"
>> by one, leads to an error:
>>
>> ```
>> | quantity | value  |
>> |--+|
>> | A| 1  |
>> | B| 3  |
>> |--+|
>> | *C*  | *0.33* |
>> | D| #ERROR |
>>
>> #+TBLFM: @4$2=@-2/@-1; *%.2f*::@5$2=@-1+1
>> ```
>>
>> I wonder if there is a way around this effect?
>
> The error here is that `*0.33*' is no longer a string that can be
> converted to a number, so the calculator barfs.

Yes, that is obvious. The underlying question is whether it is possible
to cleanly separate presentation from contents. Here they are mixed.

All the best,

Jarmo

Re: Org table: emphasizing calculated cell

[Jarmo Hurri]

Greetings Norwid.

Norwid Behrnd  writes:

> try extending the format of the table formula with asterisks, i.e.
>
> ```
> | quantity |  value |
> |--+|
> | A|  1 |
> | B|  3 |
> |--+|
> | *C*  | *0.33* |
>
> #+TBLFM:  @4$2=@-2/@-1; *%.2f*
> ```
>
> Subsequently, issue the call ```C-c *``` for an update while the
> cursor is within the table.  This approach works well enough for me
> (equally for emphasis with enclosing forward slashes, or underscores)
> in Emacs' native display (backed by elpa-org 9.4.0) as well as for a
> subsequent export into .html and display (e.g., in Firefox), or .tex.

Excellent, this is a working solution for the basic case. Much
appreciated!

This solution seems to change the contents of a cell, not only its
formatting. So the following, where I try to increase the value of "C"
by one, leads to an error:

```
| quantity | value  |
|--+|
| A| 1  |
| B| 3  |
|--+|
| *C*  | *0.33* |
| D| #ERROR |
#+TBLFM: @4$2=@-2/@-1; *%.2f*::@5$2=@-1+1
```

I wonder if there is a way around this effect?

Jarmo

Org table: emphasizing calculated cell

[Jarmo Hurri]

Greetings.

In the table below, the text in the first column of the last row is
emphasized. What is (an easy way) to emphasize the calculated value in
the second column of the last row?

| quantity | value |
|--+---|
| A| 1 |
| B| 3 |
|--+---|
| *C*  |  0.33 |
#+TBLFM: @4$2=@-2/@-1;%.2f

All the best,

Jarmo

Re: The fate of ditaa.jar (9.4.5.)

[Jarmo Hurri]

Greetings.

"Dr. Arne Babenhauserheide"  writes:

> Arthur Miller  writes:
>
>> By the way, how difficult is to download one file from the internet
>> (ditaa.jar) if you are an user?
>
> That’s not the point. The point is that every single user with a ditaa
> block has to do it.
>
> Ask the other way round: What is the benefit of removing ditaa from
> org?  If you want to force most current org-ditaa users to unbreak
> their setup after update, there should be a significant tangible
> benefit.

I agree.

One thing I like about org is that most things work out of the box.
While I can download/install/compile/whatever ditaa.jar, having to do so
adds a step. This extra step will result in fewer people using the
combination of org and ditaa. I do not think that is a good direction.

Comparing ditaa to latex/java/C/such does not feel fair, since distros
support standard software, and ditaa does not seem to qualify. But this
is an assumption. At least my distro does not support ditaa in a
package.

Just my opinion. As always, happy to leave the final decision to the
wise ones.

Have fun and stay safe!

Jarmo

Invalid duration format (9.4.5)

[Jarmo Hurri]

Greetings.

To get my work done, I had to switch from master branch to stable, but
now I started getting "invalid duration format" error when trying to
create my daily agenda:

org-duration-to-minutes: Invalid duration format: #("12:45-14:15 +1w" 0 15 
(fontified nil org-category "schedule"))

Here is the corresponding row, and the preceding row, from file
schedule.org:

<2021-04-15 Thu 09:15-10:45 +1w>
<2021-04-19 Mon 12:45-14:15 +1w>

Any hints?

Jarmo

The fate of ditaa.jar (9.4.5.)

[Jarmo Hurri]

Greetings.

I pulled the latest master and noticed that contrib has been moved into
a separate repository. I also cloned this contrib repository, but can
not find the file

scripts/ditaa.jar

in the repo. In fact, there is no directory scripts in the repo.

The documentation in the latest master states that

Stathis Sideris wrote the ‘ditaa.jar’ ASCII to PNG converter that is now
packaged into the org-contrib repository.

How should I proceed? Should I build this separately

https://github.com/stathissideris/ditaa

or will it still be included into contrib?

Have fun and stay safe!

Jarmo

Org babel java: adding class path

[Jarmo Hurri]

Greetings.

I need to add an additional classpath to the call of
org-babel-java-command to make sure my program is able to load a
database driver. But, as it is now, org babel java already uses
classpath option -cp, and in the case of multiple -cp options, only the
last one is retained:

https://stackoverflow.com/questions/45291354/specifying-multiple-cp-or-classpath-entries-on-java-command-line

So what is the correct way to do achieve this in org babel?

>From the command line, in linux, multiple class paths would separated by
a colon ":"

java -classpath "/usr/share/java/hsqldb.jar:." Main

Have fun and stay safe,

Jarmo

Re: Missing line breaks in Beamer with alltt

[Jarmo Hurri]

Hi there Eric.

Eric S Fraga  writes:

>> I will take you up on that offer! Are you able to replicate the
>> difference between these two slides?
>
> Interesting.  It seems that the use of =...= in one of the items makes
> org insert the "fragile" option for the frame and that allows the alltt
> environment to work properly.  The solution therefore is either make
> sure that there is at least one use of =...= in the slide or, better
> yet, add the fragile option yourself by setting the BEAMER_opt property
> to fragile, as in:
>
> * Another slide
> :PROPERTIES:
> :BEAMER_opt: fragile
> :END:
>
> I've tested this and it works for me.

Works for me too, excellent!

I have an eerie feeling that this should be either
a) fixed so that it works without inserting fragile, or
b) written down somewhere in documentation.
Any ideas?

All the best, and stay safe.

Jarmo

Re: Missing line breaks in Beamer with alltt

[Jarmo Hurri]

Hi there.

Eric S Fraga  writes:

> Happy to try to help.

I will take you up on that offer! Are you able to replicate the
difference between these two slides?

# 
--
#+startup: beamer

#+latex_header: \usepackage{alltt}

* A slide with some code
  - =yes= verbatim on this line, line breaks preserved
#+begin_alltt 
N=5
if S\neq I
#+end_alltt

* Another slide
  - no verbatim on this line, line breaks not preserved
#+begin_alltt 
N=5
if S\neq I
#+end_alltt

# 
--

If you are not, then please find attached generated tex.

All the best, and stay safe.

Jarmo



beamer-alltt.tex
Description: latex

Re: Missing line breaks in Beamer with alltt

[Jarmo Hurri]

Eric S Fraga  writes:

Hi there!

> On Sunday, 29 Nov 2020 at 11:22, Jarmo Hurri wrote:
>> Any ideas?
>
> First of all, the first frame works just fine for me.  Line breaks are
> preserved.

Fascinating: it has to be something in my settings. I went through my
init files and did not find anything relevant. Off to debug I go then.

> When in doubt, export to LaTeX (C-e l b) and have a look at the LaTeX.
> Also then run pdflatex yourself on that LaTeX code to see what errors
> come up.

I did that but did not notice anything weird in the latex code. Then
again, if I export to regular latex, line breaks are preserved just
fine. Therefore, this has to be related to some beamer settings (or my
texlive version or something like that).

Thanks for pointing me in the right direction.

All the best, and stay safe.

Jarmo

Missing line breaks in Beamer with alltt

[Jarmo Hurri]

Greetings.

Any ideas?

# 
--
#+startup: beamer

#+latex_header: \usepackage{alltt}

* A slide with some code
  - export to beamer pdf with =C-e l O=
  - line breaks disappear from this:
#+begin_alltt 
x \in {0, 1, ..., n}
z \leftarrow x + 1
#+end_alltt

* An effort to fix this
  - tip from

https://tex.stackexchange.com/questions/68064/beamer-alltt-environment-and-only
  - the effort is here, but the end result is an error
#+begin_src latex
  \defverbatim\SomeCode{
  \begin{alltt}
  x \in {0, 1, ..., n}
  z \leftarrow x + 1
  \end{alltt}
  }
#+end_src

\SomeCode
# 
--

All the best, and stay safe.

Jarmo

org-indent-line of lines ending blocks

[Jarmo Hurri]

Greetings.

# 
---
* Indentation of lines ending blocks
  #+begin_example
My wish is that when the cursor is on the line indicating end of this block 
(end_example), 
and (org-indent-line) is evaluated, the line would be indented at the level 
of the 
begin_example which begins the block. Is this feasible / possible?
#+end_example
# 
---

All the best, and stay safe.

Jarmo

Re: [PATCH] ob-java

[Jarmo Hurri]

ian martins  writes:

>> > It seems that you have changed some classloader settings in the new
>> > code. I have examples which used to work perfectly; now they still
>> > compile, but fail to run, throwing exception
>> >
>> > java.lang.NoClassDefFoundError
>>
>> I had some extra time today, so I took a look at ob-java.el. Unless
>> header argument dir is set, java is run in a temporary directory. So I
>> can get around this problem by setting header argument
>>
>> :dir "."
>>
>> which is nice, at least as a workaround.
>
> You're right that this is a change. I will revert the default
> behaviour. in the meantime you could do something like
>
> (setq org-babel-default-header-args:java
>   (cons '(:dir . ".")
> org-babel-default-header-args:java))
>
> in your init file after loading org to fix it everywhere.

Thanks a bunch, will do.

All the best, and stay safe.

Jarmo

Re: [PATCH] ob-java

[Jarmo Hurri]

Hi again!

Jarmo Hurri  writes:

> It seems that you have changed some classloader settings in the new
> code. I have examples which used to work perfectly; now they still
> compile, but fail to run, throwing exception
>
> java.lang.NoClassDefFoundError

I had some extra time today, so I took a look at ob-java.el. Unless
header argument dir is set, java is run in a temporary directory. So I
can get around this problem by setting header argument

:dir "."

which is nice, at least as a workaround.

I am not sure what the default behaviour should be. At the moment,
though, I do not think temporary dir is a good default, because by
default the program will then the "miss" all opened (data) files as
well. Right?

Perhaps all babel languages have a common policy here that I am not
aware of.

But in any case it looks to me that the behaviour has changed now, so if
it is changed in the stable branch (I am running master), I think it
should be documented clearly (as an incompatible change). Perhaps it
already is documented like that.

All the best, and stay safe.

Jarmo

Re: [PATCH] ob-java

[Jarmo Hurri]

ian martins  writes:

> Let me know how it goes.

Hello again.

It seems that you have changed some classloader settings in the new
code. I have examples which used to work perfectly; now they still
compile, but fail to run, throwing exception

java.lang.NoClassDefFoundError

explained here:

https://stackoverflow.com/questions/17973970/how-to-solve-java-lang-noclassdeffounderror

I have attached a minimal example demontrating the problem.

1. You can see the error if you evaluate the code in the org
   file. Please observer that the submodule java file has been compiled
   to a class just fine.
   
2. If you untangle the org file, and then run

   javac LoadError.java
   java LoadError

   you should see that there is no problem with the code.

This issue is critical for me, because a lot of code I have depends on
other code (in git submodules).

Can you please tell me how this proceeds? (I may have to roll back to an
earlier org version soon.)

All the best,

Jarmo



load-error.tar.gz
Description: load error demo

Re: [PATCH] ob-java

[Jarmo Hurri]

Hello Ian!

ian martins  writes:

> Let me know how it goes.

The new version seems to be sensitive to whitespace:

# -
* this one works
  #+begin_src java :classname Foo :results output
public class Foo
{
  public static void main(String[] args)
  {
System.out.print("hello, world");
  }
}
  #+end_src

  #+RESULTS:
  : hello, world

* this one does not (space after word =main=)
  #+begin_src java :classname Foo2 :results output
public class Foo2
{
  public static void main (String[] args)
  {
System.out.print("hello, world");
  }
}
  #+end_src
# -

All the best,

Jarmo

Re: [PATCH] ob-java

[Jarmo Hurri]

Hello Ian.

ian martins  writes:

>> Being a heavy user, I wonder if worg documentation page is being kept
>> up to date with the changes?
> Yes, that page is up to date. Actually, the page is new.

Brilliant! So the only thing that was not up to date was me.

(I wonder if it would be possible to have timestamps in worg. I have
bumped into situations before where I have not known the temporal
relationship between worg documentation and current org version.)

> Are you using the latest? 

Yes.

> Were there any issues when you updated?

At some point I was using the latest at that time, and my org java stuff
broke in the middle of a presentation during class. I have not had the
time to check whether the very latest solves these issues. I will start
preparing some new material now, and will let you know if anything weird
happens.

I greatly appreciate the effort you are putting into this package.

All the best, and stay safe.

Jarmo

Re: [PATCH] ob-java

[Jarmo Hurri]

Hi there!

I noticed that a lot of work is being put into Java in Babel. Excellent.

Being a heavy user, I wonder if worg documentation page is being kept up
to date with the changes?

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

All the best, and stay safe.

Jarmo

Re: Special symbols with monospace

[Jarmo Hurri]

Eric S Fraga  writes:

> In that case, you may simply wish to use the alltt environment.  This
> works for me:
>
> #+begin_src org
>   ,* algorithm pseudo code
>   ,#+latex_header: \usepackage{alltt}
>   ,#+begin_alltt
>   for i \in [0,1] do
> if i \neq 3
>   x ← i^2
> end if
>   end for
>   ,#+end_alltt
> #+end_src

Excellent, works for me too.

What a great community!

Jarmo

Re: Special symbols with monospace

[Jarmo Hurri]

Maxim Nikulin  writes:

 What is the easiest way to combine monospace and special symbols?
>>>
>>> Is there any problem with UTF-8 symbols such as "≠"? I have typed it using
>>> Compose / =
>> 
>> At least out of the box, the UTF-8 symbol is not exported.
>
> #+BEGIN_SRC emacs-lisp
> (add-to-list 'org-latex-inputenc-alist '("utf8" . "utf8x"))
> #+END_SR

Noice!

Thanks,

Jarmo

Re: Special symbols with monospace

[Jarmo Hurri]

Hello.

Maxim Nikulin  writes:

> Jarmo Hurri wrote:
>> What is the easiest way to combine monospace and special symbols?
>
> Is there any problem with UTF-8 symbols such as "≠"? I have typed it using
> Compose / =

At least out of the box, the UTF-8 symbol is not exported.

All the best,

Jarmo

Re: Special symbols with monospace

[Jarmo Hurri]

Hi there.

Eric S Fraga  writes:

> I resort to LaTeX for this, using a LaTeX src block with the algorithm
> and algpseudocode packages.

In my case there is a specific pseudocode format I need to use. I think
I would have to try to tune one of these packages pretty heavily.

But I will see. Thanks.

Jarmo

Re: Special symbols with monospace

[Jarmo Hurri]

Hi there!

Colin Baxter  writes:

> Would https://github.com/jsalzbergedu/pseudocode-mode be any good?

I will have to explore it. The documentation is almost as thin as my
wallet.

Thanks,

Jarmo

Special symbols with monospace

[Jarmo Hurri]

Greetings.

I like to embed pseudocode etc. in example blocks so that it is typeset
in monospace when exported. But sometimes I would need special symbols,
such as \neq, in pseudocode. What is the easiest way to combine
monospace and special symbols?

Jarmo

Re: Bug: links to filename containing word "loops" fail to export

[Jarmo Hurri]

Nicolas Goaziou  writes:

>> * Links to files containing the word ~loops~ are not exported
>
> Fun bug. 

Indeed! Had to take a second cup of coffee before I believed my eyes.

> This should be fixed

Seems to be working now, thank you very much.

All the best, and stay safe.

Jarmo

Bug: links to filename containing word "loops" fail to export

[Jarmo Hurri]

* Links to files containing the word ~loops~ are not exported
** What is the problem?
   It seems that if a link to a file contains the word ~loops~,
   it is not exported at all.
** How to replicate
   1. Save this org into file =org-loops-in-link.org=
   2. Save the following elisp into =minimal-org.el=, replacing the
 location of org mode with your path:
 #+begin_src elisp
   (add-to-list 'load-path (expand-file-name "~/src/org-mode/lisp"))
   (add-to-list 'load-path (expand-file-name "~/src/org-mode/contrib/lisp" 
t))
 #+end_src
   3. Open this file with
  #+begin_src sh
emacs -Q -l minimal-org.el org-loops-in-link.org
  #+end_src
   4. Export to latex as a PDF file and open (C-c C-e l o), observing
  missing items when the list below is exported:
  - [[file:loopy.org]]
  - [[file:loops.org]]
  - [[file:loopz.org]]
  - [[file:some-loops.org]]
  - [[file:some-loopz.org]]
** My org and emacs versions
   - Org mode version 9.3.7 (release_9.3.7-708-g5417e3)
   - GNU Emacs 26.3

Re: Binding RET to org-return-and-maybe-indent

[Jarmo Hurri]

Greetings Kévin.

Kévin Le Gouguec  writes:

> If I replace (electric-indent-mode -1) with
> (electric-indent-local-mode -1) in org-mode-hook, I get the behaviour
> we have with "Org 9.3" and "Org master, electric-indent-mode on".
>
> Can you tell me whether electric-indent-local-mode works better for
> you?  If it does, I'll followup with a patch to ORG-NEWS.

Seems to be working fine. Thank you very much.

All the best, and stay safe.

Jarmo

Re: Binding RET to org-return-and-maybe-indent

[Jarmo Hurri]

Hi Kévin.

Kévin Le Gouguec  writes:

>>> #+begin_src emacs-lisp
>>> (add-hook 'org-mode-hook (lambda () (electric-indent-mode -1)))
>>> #+end_src
>>
>> Unfortunately this has side effects: it changes at least the way
>> parentheses and indentation interact when opening a Babel source code
>> block. It might be a good idea to mention this in ORG-NEWS.
>
> Could you give us a precise recipe?  (Starting from emacs -Q and an
> empty Org buffer)
>
> I've fiddled a bit with source blocks just now and I'm noticing some
> weirdness that I suspect might be due to electric-indent-mode
> re-indenting the previous line when hitting RET (or C-j when disabling
> electric-indent-mode), but nothing specific to parentheses.

At the minimum it changes the way parentheses indent automatically when
editing source code blocks. Below is a minimal demo, documented using
our favorite system.

All the best, and stay safe.

Jarmo

* Demo of the effect of disabling elint
  1. Save this org into file =org-elint-disable.org=
  2. Save the following elisp into =minimal-org.el=, replacing the
 location of org mode with your path:
 #+begin_src elisp
   (add-to-list 'load-path (expand-file-name "~/src/org-mode/lisp"))
   (add-to-list 'load-path (expand-file-name "~/src/org-mode/contrib/lisp" 
t))
   (add-hook 'org-mode-hook (lambda () (electric-indent-mode -1)))
 #+end_src
  3. Toggle the last line
 #+begin_src elisp
 (add-hook 'org-mode-hook (lambda () (electric-indent-mode -1)))
 #+end_src
 in =minimal-org.el= to see the following effect:
 1. Open this file with
#+begin_src sh
  emacs -Q -l minimal-org.el org-elint-disable.org
#+end_src
 2. Type C-c ' for (org-edit-special) in the source code block below,
and follow the instructions on the comment line.
#+begin_src java :exports none :classname Demo
  class Demo
  {
  // 1st press RET at the end of this line, then type TAB and }
#+end_src
  

Re: Binding RET to org-return-and-maybe-indent

[Jarmo Hurri]

Hello again.

Kévin Le Gouguec  writes:

> As ORG-NEWS notes, if you want RET to stop indenting, you can disable
> electric-indent-mode in org-mode-hook:
>
> #+begin_src emacs-lisp
> (add-hook 'org-mode-hook (lambda () (electric-indent-mode -1)))
> #+end_src

Unfortunately this has side effects: it changes at least the way
parentheses and indentation interact when opening a Babel source code
block. It might be a good idea to mention this in ORG-NEWS.

Next I will try to change the binding of RET.

All the best, and stay safe.

Jarmo

Re: Binding RET to org-return-and-maybe-indent

[Jarmo Hurri]

Hello Kévin.

Kévin Le Gouguec  writes:

> RET indentation is something that has been introduced recently on the
> master branch (which will become Org 9.4 soon).  In Org 9.3, with your
> example, RET does not indent, while C-j does.

I was wondering why this bothered me! Such a little thing can have a
drastic effect on your workflow when it is repeated so many times.

> As ORG-NEWS notes, if you want RET to stop indenting, you can disable
> electric-indent-mode in org-mode-hook:

Thanks, I now located this feature change description in ORG-NEWS.

>> But would changing the binding of RET cause issues elsewhere?
>
> I can't think of any bad side-effect, but my imagination might be
> lacking.  The only downside I can think of is that RET will become
> redundant with C-j.

Now I have two options. I will start by disabling electric-indent-mode
in org. If that causes weird side effects, then I will rebind RET.

Thank you for your most complete answer.

All the best, and stay safe.

Jarmo

Binding RET to org-return-and-maybe-indent

[Jarmo Hurri]

Hello.

Is there any downside to binding RET to org-return-and-maybe-indent?

I want to remove RET indentation in org mode. For example

# ---
* Demo of indentation
  - when I press return at the end of the word THIS
  - I get indentation
# ---

However, if I call org-return-and-maybe-indent at the same point, I do
not get indentation.

But would changing the binding of RET cause issues elsewhere?

I am running Org mode version 9.3.7 (release_9.3.7-694-g7069dc).

Jarmo

Re: Error (args out of range) when editing list

[Jarmo Hurri]

Nicolas Goaziou  writes:

>> I think I am running the latest (stable) master:
>
> Note: stable ≠ master, so you just wrote an oxymoron ;)

Oops, exactly. :) I now pulled the latest _master_, and it does not have
the same issue branch _stable_ has. So I guess stable will also contain
the fix at some point.

Thanks, and all the best,

Jarmo

Re: Error (args out of range) when editing list

[Jarmo Hurri]

Hi there!

Nicolas Goaziou  writes:

>> * Demo of some sort of error
>>   1. (take your cursor on top of the letter X after the closing
>>  parenthesis)X
>>   2. then press Alt-Enter
>>  1. you will notice
>>  2. an error
>>   3. saying something like args out of range
>
> Could you try with latest master? I cannot reproduce it.

I think I am running the latest (stable) master:

Org mode version 9.3.7 (release_9.3.7-13-ge62ca4)

Then it has to be something in my system. Great. As a cry for help, here
is what I get with debug-on-error:

Debugger entered--Lisp error: (args-out-of-range -1 3)
  replace-match("2. " nil nil nil 1)
  #f(compiled-function (struct old-struct item) #)(((30 2 
"1. " nil nil nil 112) (112 2 "2. " nil nil nil 119) (120 2 "1. " nil nil nil 
187) (146 5 "1. " nil nil nil 170) (170 5 "2. " nil nil nil 187) (187 2 "2. " 
nil nil nil 232)) ((30 2 "1. " nil nil nil 112) (112 2 "1. " nil nil nil 119) 
(120 2 "2. " nil nil nil 187) (146 5 "1. " nil nil nil 170) (170 5 "2. " nil 
nil nil 187) (187 2 "3. " nil nil nil 232)) 187)
  org-list-struct-apply-struct(((30 2 "1. " nil nil nil 112) (112 2 "2. " nil 
nil nil 119) (120 2 "1. " nil nil nil 187) (146 5 "1. " nil nil nil 170) (170 5 
"2. " nil nil nil 187) (187 2 "2. " nil nil nil 232)) ((30 2 "1. " nil nil nil 
112) (112 2 "1. " nil nil nil 119) (120 2 "2. " nil nil nil 187) (146 5 "1. " 
nil nil nil 170) (170 5 "2. " nil nil nil 187) (187 2 "3. " nil nil nil 232)))
  org-list-write-struct(((30 2 "1. " nil nil nil 112) (112 2 "2. " nil nil nil 
119) (120 2 "1. " nil nil nil 187) (146 5 "1. " nil nil nil 170) (170 5 "2. " 
nil nil nil 187) (187 2 "2. " nil nil nil 232)) ((30) (112) (120) (146 . 120) 
(170 . 120) (187)))
  org-insert-item(nil)
  funcall-interactively(org-insert-item nil)
  call-interactively(org-insert-item)
  org-meta-return(nil)
  funcall-interactively(org-meta-return nil)
  call-interactively(org-meta-return nil nil)
  command-execute(org-meta-return)

All the best,

Jarmo

Error (args out of range) when editing list

[Jarmo Hurri]

* Demo of some sort of error
  1. (take your cursor on top of the letter X after the closing
 parenthesis)X
  2. then press Alt-Enter
 1. you will notice
 2. an error
  3. saying something like args out of range

Re: Babel: parse error when output contains opening bracket

[Jarmo Hurri]

ian martins  writes:

> Since you recommend it, I will try submitting a patch for java.

Excellent.

> I still want to share the haxe integration. What is the best way to do
> that?

What does "haxe integration" mean here?

All the best,

Jarmo

Re: Babel: parse error when output contains opening bracket

[Jarmo Hurri]

>> ian martins  writes:
>> 
>> Would it be possible for us to fix the current version without
>> introducing a new one? Can you identify the parts of your code that fix
>> the issue?
>>
> The existing code creates the java program and runs it correctly, but
> it uses `org-babel-import-elisp-from-file' to interpret the results,
> and that sees the bracket and tries to make the response into a list,
> and errors when it can't. I don't see a quick fix for it. If you allow
> unbalanced brackets but that would be a change in ob-core and would
> probably cause unwanted results in other places. If you don't try to
> convert the output into a list, you can't present java results as
> lists or tables.  Really the problem is that ob-java doesn't support
> functional mode, so it tries to guess if scripting mode output should
> be a table or list.  The version I wrote supports functional and
> scripting modes and doesn't use `org-babel-import-elisp-from-file'.

Ok.

>> I am already a contributor, so if you can post your solution here I
>> can create a patch and give you the credit.
>>
> I would really appreciate that if you are willing, but it's a
> significant change (code is 400 lines, 600 lines of tests and test
> data) and there might be iterations so you might be signing up for
> more than you realize.

Fair enough.

1. Have you considered writing a patch yourself?

2. If not, I think you lose nothing by posting your code here and
   patiently waiting if I can create something out of it.

All the best,

Jarmo

Re: Babel: parse error when output contains opening bracket

[Jarmo Hurri]

ian martins  writes:

Hello.

> I've written an alternative org-java.el that doesn't have that
> problem. I wanted to add it to contrib/ but haven't been able to get
> access. if you want to try it I can post it somewhere.

Sounds excellent.

Would it be possible for us to fix the current version without
introducing a new one? Can you identify the parts of your code that fix
the issue?

I am already a contributor, so if you can post your solution here I can
create a patch and give you the credit.

How does that sound?

Jarmo

Babel: parse error when output contains opening bracket

[Jarmo Hurri]

Greetings.

In the org file below, the first babel block will evaluate just fine,
while the second will signal "End of file during parsing". The
difference is the opening bracket "[" in output.

I think am running the most recent stable version:
Org mode version 9.3.7 (release_9.3.7-4-gba6ca7)

Thanks for any ideas.

Jarmo

# ---
* This will parse just fine
  #+name: OK
  #+begin_src java :exports results :classname OK :results output
class OK
{
  public static void main (String[] args) { System.out.println ("foo"); }
}
  #+end_src

  #+RESULTS: OK
  : foo

* This will generate a parse error when evaluated
  #+name: BAD
  #+begin_src java :exports results :classname BAD :results output
class BAD
{
  public static void main (String[] args) { System.out.println ("[foo"); }
}
  #+end_src

Re: Bug: org-insert-item behaves weirdly and then fails

[Jarmo Hurri]

Nicolas Goaziou  writes:

> Indeed. This should now be fixed.

Was that quick or what!? Kudos.

Jarmo

Bug: org-insert-item behaves weirdly and then fails

[Jarmo Hurri]

Greetings.

The following happens with the latest version of the stable branch and
the latest version of the master branch.

Consider the following org file:

# ---
1. Some text [fn:: foo]

2. 

3. with items
# ---

The bug can be reproduced with the following:
1. go to the end of first line
2. press M-return , that is (org-meta-return)
3. return to step 1

You will notice that item numbers will first start to behave weirdly,
then eventually an error will be thrown.

My emacs version is

GNU Emacs 26.3

Any ideas?

Jarmo

Latex export: setting options for packages included by default

[Jarmo Hurri]

Greetings.

When I export to Latex, org automatically creates the following line in
preamble:

\usepackage{color}

I would like to find a way to pass option [monochrome] to this
package. Adding another \usepackage creates a conflict. My preferred way
would be to add the line

\PassOptionsToPackage{monochrome}{color}

to the preamble before \usepackage.

1. Is there a way to do this (easily) in Org? I think it is possible to
   redefine the preamble template, but that would be an overkill.

2. If there is no direct option for this, could we have one? Like
   #+latex_header but which would be applied before any packages are
   loaded?

Jarmo

Re: Asymptote figure in footnote

[Jarmo Hurri]

Nicolas Goaziou  writes:

>> This has to be a borderline case, but I need some Asympote-generated
>> figures in footnotes. The following does not seem to work.
>>
>> [fn:: src_asy[:filename foo.pdf]{size(8cm,0); draw (unitcircle);}]
>
> The following works here:
>
>   [fn:: src_asymptote[:file foo.pdf]{size(8cm,0); draw (unitcircle);}]

Thank you and sorry.

That was pathetic, but it has been a long day. And continues.

Do you have an idea of how to control the size of the pic in the
footnote? The default is .9\linewidth. I figured a workaround (below),
but would prefer the structure above.

The workaround is to produce the asy image with a regular src block,
exporting nothing, and then using inline latex in footnote as follows:

[fn:: @@latex:\includegraphics[width.3\linewidth]{sine-curve-a.pdf}@@]

And, once again, I am amazed by Org's capabilities! :D

Jarmo

Asymptote figure in footnote

[Jarmo Hurri]

Greetings.

This has to be a borderline case, but I need some Asympote-generated
figures in footnotes. The following does not seem to work.

[fn:: src_asy[:filename foo.pdf]{size(8cm,0); draw (unitcircle);}]

Any ideas?

Jarmo

Re: [PATCH] ob-java.el: Add header argument to pass command line args

[Jarmo Hurri]

Greetings.

I posted an updated version of the patch here on December 1st, but I
have not yet seen it in the master branch so far. Was the patch ok, or
do I still need to do something else than wait?

As a new year approaches, I too want to thank everyone involved in Org
for creating such a great tool. I use it for all my work currently.

All the best,

Jarmo

Re: Include lines in setupfile are not evaluated: bug or feature?

[Jarmo Hurri]

Greetings again.

Nicolas Goaziou  writes:

>> Ok. As a programmer I was hoping to mix them, because it would be
>> logical to have _one_ header file that defines all the common things
>> for a set of related files.
>
> Again, there is no overlap between the two keywords. SETUPFILE is what
> you want. INCLUDE is only meaningful during export (and is only
> documented there). I cannot think of a real situation where you would
> need both for the same file.

I have such documents regularly.
1. One type is a handout containing common contents at the beginning
   (included) and settings (setup).
2. The other case is a set of files sharing setup info and code (babel
   blocks, included).

>> Do I understand correctly: the description in the documentation is
>> not correct in the sense that not all contents from SETUPFILE is
>> evaluated as if it were included in the buffer?
>
> I think the document is correct, although I understand it can be
> misleading: it uses the verb "to include", but with a different
> meaning than INCLUDE keyword. It includes in-buffer settings, not full
> contents.
>
>> I am just trying to think about how this limitation, if it exists,
>> should be expressed in documentation. Shall I give it a try?
>
> Sure, but please do not mix SETUPFILE and INCLUDE, which are
> unrelated.

I will give it a try during the Christmas break.

All the best,

Jarmo

Re: Include lines in setupfile are not evaluated: bug or feature?

[Jarmo Hurri]

Hello Nicolas!

Nicolas Goaziou  writes:

> SETUPFILE and INCLUDE are orthogonal. There is no point in mixing
> them.

Ok. As a programmer I was hoping to mix them, because it would be
logical to have _one_ header file that defines all the common things for
a set of related files.

But perhaps I can get away with using SETUPFILEs only. I will see.

> Jarmo Hurri  writes:
>> Documentation of #setupfile says that
>>
>> "Org parses the contents of this document as if it was included in the
>> buffer."
>>
>> https://orgmode.org/manual/In_002dbuffer-settings.html
>>
>> But that does not seem to be the case.
>
> SETUPFILE keyword recursively loads configuration from other files,
> without inserting anything. INCLUDE keyword recursively inserts
> contents from other files in the current document, but there is no
> guarantee that configuration from these files will be inherited.

Do I understand correctly: the description in the documentation is not
correct in the sense that not all contents from SETUPFILE is evaluated
as if it were included in the buffer?

I am just trying to think about how this limitation, if it exists,
should be expressed in documentation. Shall I give it a try?

Thanks for the clarifying response!

Jarmo

Include lines in setupfile are not evaluated: bug or feature?

[Jarmo Hurri]

Greetings.

I am (still) trying to figure out a SINGLE common setup/include file for
all settings for a large batch of files.

I found out recently that common #properties can be set in a setup file
(but not in an included file). However, now it seems that in a setup
file I can not include all common included files. Is this intended
behaviour?

Below is an example that demonstrates this. First the main (exported
file):

# --- file main-file.org 
#+setupfile: setup-file.org

src_elisp[:exports results :results raw]{(org-entry-get nil "MY_PROPERTY" t)}
# ---

Then the setup file:

# -- file setup-file.org 
#+property: MY_PROPERTY true
#+include: setup-included.org
# ---

Then the file that is supposed to be included in the setup file (and,
consequently, in the main file):

# -- file setup-included.org 
Some text to be included.
# ---

But the text is not included in the main file. Documentation of
#setupfile says that

"Org parses the contents of this document as if it was included in the
buffer."

https://orgmode.org/manual/In_002dbuffer-settings.html

But that does not seem to be the case.

Jarmo

PATCH: Display point of code block point when confirming evaluation

[Jarmo Hurri]

Greetings.

Please find attached a patch that adds the point of the source code
block to the message shown to user when confirming the evaluation of the
block.

In large org-files, I have often trouble figuring out which code block
Org is confirming me to evaluate when exporting. This is especially true
when I have set 'cache: yes'. When something changes in code, these
blocks need to be re-evaluated during export, but the '#results:' of
these blocks are not changed. Therefore, on the next export I will be
asked again, unless I find the block and evaluate it by hand myself.

This patch adds the 'start' element of source block info at the end of
the confirmation message. 

Jarmo

>From aaa68af8a7710ffe2c61fc45edf2ff377438cd32 Mon Sep 17 00:00:00 2001
From: Jarmo Hurri 
Date: Sat, 7 Dec 2019 09:14:34 +0200
Subject: [PATCH] ob-core.el: Display block point during evaluation
 confirmation

* lisp/ob-core.el (org-babel-confirm-evaluate): Display code block
point when querying confirmation of evaluation.

This addresses the problem of finding the block currently evaluated.
---
 lisp/ob-core.el | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index f877ff51b..7ba9894e6 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -277,7 +277,8 @@ environment, to override this check."
   (let* ((evalp (org-babel-check-confirm-evaluate info))
 	 (lang (nth 0 info))
 	 (name (nth 4 info))
-	 (name-string (if name (format " (%s) " name) " ")))
+	 (name-string (if name (format " (%s) " name) " "))
+	 (start (nth 5 info)))
 (pcase evalp
   (`nil nil)
   (`t t)
@@ -285,11 +286,11 @@ environment, to override this check."
 	   (and (not (bound-and-true-p
 			  org-babel-confirm-evaluate-answer-no))
 		(yes-or-no-p
-		 (format "Evaluate this %s code block%son your system? "
-			 lang name-string)))
+		 (format "Evaluate this %s code block%son your system (point %d)? "
+			 lang name-string start)))
 	   (progn
-		(message "Evaluation of this %s code block%sis aborted."
-			 lang name-string)
+		(message "Evaluation of this %s code block%sis aborted (point %d)."
+			 lang name-string start)
 		nil)))
   (x (error "Unexpected value `%s' from `org-babel-check-confirm-evaluate'" x)
 
-- 
2.21.0

Re: Included global properties not inherited: bug or feature?

[Jarmo Hurri]

Nicolas Goaziou  writes:

>> I find current behaviour inconvenient, because I want to set common
>> global properties for a large number of files, and I can not currently
>> do this via an included file.
>
> What happens if you use SETUPFILE instead?

It works perfectly.

Please find attached a patch that mentions this behaviour in the
include-part of Org manual. Ok?

Jarmo

>From 00701e1732fcf71180dc02f72117b44bccf5eb2d Mon Sep 17 00:00:00 2001
From: Jarmo Hurri 
Date: Sat, 7 Dec 2019 08:19:05 +0200
Subject: [PATCH] org-manual.org: Document global properties not being
 inherited when including files

* doc/org-manual.org: Note that when an org-file is included, even
  with `:only-contents` set to `nil`, global properties set with lines
  beginning `#+PROPERTY:` will not be inherited in the file that
  includes. Point the user to use `#+SETUPFILE:` for this purpose.
---
 doc/org-manual.org | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 35f6013ce..a0aedf825 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -11770,6 +11770,11 @@ with the custom ID =theory=, you can use
 
 : #+INCLUDE: "./paper.org::#theory" :only-contents t
 
+Note that even when =:only-contents= has value ~nil~, properties set
+in the included file by lines beginning with =#+PROPERTY:= will not be
+inherited in the file that includes. To achieve such inheritance, use
+=#+SETUPFILE:= instead (see [[Summary of In-Buffer Settings]]).
+
 The following command allows navigating to the included document:
 
 - {{{kbd(C-c ')}}} (~org-edit~special~) ::
-- 
2.21.0

Included global properties not inherited: bug or feature?

[Jarmo Hurri]

Greetings.

It seems that when a file with global properties is included, the global
properties are not inherited. Is this a bug or a feature?

Consider the two files inlined below:

# -- file 'included.org' ---
#+property: MY_INCLUDED_PROPERTY some included value
# --

# -- file which includes ---

#+include: included.org :only-contents nil
#+property: MY_INLINE_PROPERTY some inline value

src_elisp[:exports results :results raw]{(org-entry-get nil 
"MY_INCLUDED_PROPERTY" t)} nil

src_elisp[:exports results :results raw]{(org-entry-get nil 
"MY_INLINE_PROPERTY" t)} some inline value
# --

As you can see from the results of evaluation of elisp blocks, the
included global property is not available in the including file. Note
that the documentation for #include states that there is a special
property :only-contents for including only contents, not properties. To
play it safe, I have set this property to 'nil' above.

https://orgmode.org/manual/Include-files.html

Based on this documentation, I was expecting global properties to be
available by default in including files.

I find current behaviour inconvenient, because I want to set common
global properties for a large number of files, and I can not currently
do this via an included file.

What is the verdict?

I am running
Org mode version 9.3 (release_9.3-34-g2eee3c)
GNU Emacs 26.2

Jarmo

Re: Babel: tangling questions

[Jarmo Hurri]

Greetings Diego.

Diego Zamboni  writes:

>> 1. I want to tangle to the default filename (derived from name of org
>>file and programming language). However, the :tangle header argument
>>only takes either "yes" or "filename." If the value is "yes", then
>>the filename is deduced automatically. How can I specify a tangling
>>directory and still have the default filename?
>
> You can specify a full path as the value of :tangle, but I don't know
> of a way to specify only the directory.

For my purposes this would be a nice new feature. Specifying a directory
would imply the default filename.

> As a workaround, you can also use emacs-lisp code as the value for
> :tangle, so you could do something like this:
>
>  :tangle (concat "/some/dir/" (file-name-base (file-name-sans-extension
> (buffer-file-name))) ".ext")

Nice! For this to be practical, I need two additional features.

1. Ability to set "/some/dir/" on a per-file basis.
2. Ability to infer ".ext" from the source block.

I was actually extend your suggestion to a solution with both of these
properties. In my emacs init file I define:

(defun org-default-tangle-file-with-dir-from-property ()
  (concat (or (org-entry-get nil "ORG_TANGLE_DIRECTORY" t) ".")
  "/"
  (file-name-base (file-name-sans-extension (buffer-file-name)))
  "."
  (let ((lang (car (org-babel-get-src-block-info t
(or (cdr (assoc lang org-babel-tangle-lang-exts)) lang

Then I set on the top of my org file, for example

#+property: ORG_TANGLE_DIRECTORY ../docs

After this the following works like a charm (at least so far):

:tangle (org-default-tangle-file-with-dir-from-property)

>> 3. Is it possible to tangle automatically on (every) export? I always
>>export, but I might forget to tangle, in which case export and tangle
>>would be out of sync.
>>
>
> I use the following hook to tangle on every save. I find it indispensable :)
>
>   (add-hook 'org-mode-hook (lambda () (add-hook 'after-save-hook
> 'org-babel-tangle
>'run-at-end 'only-in-org-mode)))

Good idea, I will explore this.

> Also, check out my free book "Literate Config", where I discuss some
> more tips about Literate Programming:
> https://leanpub.com/lit-config/read

Will do.

> Hope this helps,

Sure did. Thanks!

Jarmo

Babel: tangling questions

[Jarmo Hurri]

Greetings.

I am trying to tangle code to a specific directory.

1. I want to tangle to the default filename (derived from name of org
   file and programming language). However, the :tangle header argument
   only takes either "yes" or "filename." If the value is "yes", then
   the filename is deduced automatically. How can I specify a tangling
   directory and still have the default filename?

   There was a related question on stack exchange, but it did not use
   the default filename:
   
https://emacs.stackexchange.com/questions/41806/org-babel-set-root-dir-for-tangled-files

2. The question above implies a feature request: third possible value
   for :tangle, a directory. In this case code would be tangled into the
   specified directory into a file with default filename. Any support?

3. Is it possible to tangle automatically on (every) export? I always
   export, but I might forget to tangle, in which case export and tangle
   would be out of sync.

   Someone asked about this a while ago on stack exchange, but maybe
   things have changed:
   
https://emacs.stackexchange.com/questions/24645/exporting-and-tangling-simultaneously-in-org-mode

Thanks a bunch in advance.

Jarmo

Re: [PATCH] ob-java.el: Add header argument to pass command line args

[Jarmo Hurri]

Nicolas Goaziou  writes:

>> Any hope of this super tiny patch being applied? It addresses the
>> problem I brought up in another thread: it is currently not possible
>> to pass command line arguments to a java program.
>
> Org 9.3 is feature frozen for the time being. Do you think this
> qualifies as a bugfix or as a new feature? 

More of a new feature, I guess.

> In the latter case, could you rebase it on top of "next" branch and
> add an entry in ORG-NEWS, under "Org 9.4" section?

I did my best; see attachments. There was no 9.4 section in ORG-NEWS, so
I added my entry under "Version Next". Are these ok?

Jarmo

>From 5089053f4f3f916dfbdab009d28b16ffac6f9055 Mon Sep 17 00:00:00 2001
From: Jarmo Hurri 
Date: Wed, 6 Nov 2019 12:21:16 +0200
Subject: [PATCH 1/2] ob-java.el: Add header argument to pass command line
 args.

* lisp/ob-java.el (org-babel-execute:java): Handle new header argument `:cmdargs` and pass its value as the last element in call to java.
---
 lisp/ob-java.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index b055f85e5..80308ec32 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -58,6 +58,7 @@ parameters may be used, like javac -verbose"
 	 (src-file (concat classname ".java"))
 	 (cmpflag (or (cdr (assq :cmpflag params)) ""))
 	 (cmdline (or (cdr (assq :cmdline params)) ""))
+	 (cmdargs (or (cdr (assq :cmdargs params)) ""))
 	 (full-body (org-babel-expand-body:generic body params)))
 (with-temp-file src-file (insert full-body))
 (org-babel-eval
@@ -66,7 +67,7 @@ parameters may be used, like javac -verbose"
 (unless (or (not packagename) (file-exists-p packagename))
   (make-directory packagename 'parents))
 (let ((results (org-babel-eval (concat org-babel-java-command
-   " " cmdline " " classname) "")))
+   " " cmdline " " classname " " cmdargs) "")))
   (org-babel-reassemble-table
    (org-babel-result-cond (cdr (assq :result-params params))
 	 (org-babel-read results)
-- 
2.21.0

>From 033f455399d0821d818ef6ff1c01036c04873ddb Mon Sep 17 00:00:00 2001
From: Jarmo Hurri 
Date: Sun, 1 Dec 2019 12:26:55 +0200
Subject: [PATCH 2/2] Mention header argument to pass command arguments to Java
 blocks in ORG-NEWS

* etc/ORG-NEWS: Mention header argument :cmdargs for Java code blocks.
---
 etc/ORG-NEWS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 689a07871..ac3d1517f 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -19,6 +19,9 @@ just as if it was at outline level 0.  Inheritance for properties will
 work also for this level.  In other words; defining things in a
 property drawer before the first headline will make them "inheritable"
 for all headlines.
+*** New header argument to pass Java command line arguments
+Babel Java blocks recognize header argument =:cmdargs= and pass its
+value in call to =java=.
 
 * Version 9.3
 
-- 
2.21.0

Re: [PATCH] ob-java.el: Add header argument to pass command line args

[Jarmo Hurri]

Greetings.

Any hope of this super tiny patch being applied? It addresses the
problem I brought up in another thread: it is currently not possible to
pass command line arguments to a java program.

All the best,

Jarmo

Re: Bug: ob-plantuml: using @start prefix in buffer returns nil body due to nil assignments [N/A (N/A @ /nix/store/1hmx5h1kn25p7s31h31dz7g3kn1dc6qx-emacs-packages-deps/share/emacs/site-lisp/org/)]

[Jarmo Hurri]

Greetings Terje.

Terje Larsen  writes:

> I noticed that I cannot run C-c C-c to convert plantuml source blocks
> since the commit (4e854974be9788f029f2d73f829c4d51d2b83faf), see changes
> at:
> https://code.orgmode.org/bzg/org-mode/commit/4e854974be9788f029f2d73f829c4d51d2b83faf#diff-9c9a333463276ff17be763269a5042f92a40817R73
>
> If I have a simple source block as such as:
>
> #+BEGIN_SRC plantuml :file output.png
> @startuml
> actor Foo1
> actor Foo2
> Foo1 -> Foo2 : Test
> @enduml
> #+END_SRC
>
> When I try to run C-c C-c I receive the following error message:
> org-babel-execute-src-block: Wrong type argument: char-or-string-p,
> nil

I started using plantuml in org last week (and am enjoying it greatly),
so take this with a hint of salt from a beginner. Still, at least in my
installation, your source code block works fine without '@startuml' and
'@enduml':

#+BEGIN_SRC plantuml :file output.png
actor Foo1
actor Foo2
Foo1 -> Foo2 : Test
#+END_SRC

All the best,

Jarmo

[PATCH] ob-java.el: Add header argument to pass command line args

[Jarmo Hurri]

... attached

Jarmo

>From bbc3f977d6b98240834af8fb009a2a080813f30b Mon Sep 17 00:00:00 2001
From: Jarmo Hurri 
Date: Wed, 6 Nov 2019 12:21:16 +0200
Subject: [PATCH] ob-java.el: Add header argument to pass command line args.

* lisp/ob-java.el (org-babel-execute:java): Handle new header argument `:cmdargs` and pass its value as the last element in call to java.
---
 lisp/ob-java.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index b055f85e5..80308ec32 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -58,6 +58,7 @@ parameters may be used, like javac -verbose"
 	 (src-file (concat classname ".java"))
 	 (cmpflag (or (cdr (assq :cmpflag params)) ""))
 	 (cmdline (or (cdr (assq :cmdline params)) ""))
+	 (cmdargs (or (cdr (assq :cmdargs params)) ""))
 	 (full-body (org-babel-expand-body:generic body params)))
 (with-temp-file src-file (insert full-body))
 (org-babel-eval
@@ -66,7 +67,7 @@ parameters may be used, like javac -verbose"
 (unless (or (not packagename) (file-exists-p packagename))
   (make-directory packagename 'parents))
 (let ((results (org-babel-eval (concat org-babel-java-command
-   " " cmdline " " classname) "")))
+   " " cmdline " " classname " " cmdargs) "")))
   (org-babel-reassemble-table
(org-babel-result-cond (cdr (assq :result-params params))
 	 (org-babel-read results)
-- 
2.21.0

Babel: command line args in java

[Jarmo Hurri]

* Intro
  I am trying to supply command line arguments to java code in
  babel. For this a logical option would be to use ~:cmdline~ header
  argument, but I can not get it to work.

  I really need to process the given values as command line arguments,
  so setting some variable values will not work.

* This does not work
  Because ~ob-java.el~ concatenates ~:cmdline~ before ~:classname~ ,
  the straightforward way fails.

  #+begin_src java :classname ArgumentExample :cmdline hi there org fans 
:results output verbatim 
class ArgumentExample
{
  public static void main (String[] args)
  {
for (String s : args)
  System.out.println (s);
  }
}
  #+end_src

  #+RESULTS:

  The results is
  #+begin_center
  Error: Could not find or load main class hi
  Caused by: java.lang.ClassNotFoundException: hi
  #+end_center

  The reason is this piece of code in ~ob-java.el~
  #+begin_src elisp
(org-babel-eval (concat org-babel-java-command " " cmdline " " classname) 
"")
  #+end_src

* This compiles and runs but not as desired
  The second try is to provide classname as the first argument. But a
  ~:classname~ header is also required, so the end result is not the
  desired one.

  #+begin_src java :classname ArgumentExample :cmdline ArgumentExample hi there 
org fans :results output verbatim 
class ArgumentExample
{
  public static void main (String[] args)
  {
for (String s : args)
  System.out.println (s);
  }
}
  #+end_src

  #+RESULTS:
  : hi
  : there
  : org
  : fans
  : ArgumentExample

* This fix does not work either
  When I try to leave out ~:classname~ , the process fails in early stages.

  #+begin_src java :cmdline ArgumentExample hi there org fans :results output 
verbatim 
class ArgumentExample
{
  public static void main (String[] args)
  {
for (String s : args)
  System.out.println (s);
  }
}
  #+end_src

  #+begin_center
  org-babel-execute:java: Can’t compile a java block without a classname
  #+end_center
* Questions
  1. Is there a correct way of doing this already?
  2. If there is no better way, is this desired behaviour or should it
 be fixed?
  3. If this is desired behaviour, can I write a patch adding a new
 header argument such as ~cmdargs~ ?

Continued lists

[Jarmo Hurri]

Greetings.

I know that lists can be continued using the following syntax:

# ---
* First heading
  1. a list begins here
* Second heading
  2. [@2] list continues
# ---

I find myself doing this all the time, especially when working on Beamer
slides.

Given how smart org mode is (it is!), I find manual list continuation
weird. My questions are:

a. Is there already a better way?
b. [@b] Could we have one?

Jarmo

Re: [O] JShell support in Babel?

[Jarmo Hurri]

Ken Mankoff  writes:

Greetings.

>> JShell is a pretty nifty tool for exploring and demonstrating basic
>> Java features. Has anyone happened to write support for it in Babel?
>
> You can start working with it even without official Babel support:
>
> #+BEGIN_SRC bash :results verbatim
> jshell

That is a nice start! Thanks.

Jarmo

[O] JShell support in Babel?

[Jarmo Hurri]

Hello.

JShell is a pretty nifty tool for exploring and demonstrating basic Java
features.

https://en.wikipedia.org/wiki/JShell

Has anyone happened to write support for it in Babel?

If no-one has done this, I might try to implement it later by mimicking
some other language support. Unfortunately I have too much work on my
plate right now, so at this point I am just hoping to find something
ready.

Have fun,

Jarmo

[O] Configuring listings for file or language

[Jarmo Hurri]

Greetings.

The help documentation for the variable org-latex-listings-options
suggests that it is easy to configure these options
- globally for all files and languages using this variable
- for each code block separately using #+attr_latex

Is it possible to configure these options for all code blocks
1. in a single org file
2. for a single language?

Thanks!

Jarmo

Re: [O] Latex single dollar math delimiter question

[Jarmo Hurri]

"Fraga, Eric"  writes:

> On Sunday,  4 Aug 2019 at 08:31, Jarmo Hurri wrote:
>> Can someone explain why the single '$' characters below are not
>> recognized as math delimiters?
>>
>> a /complex number/ $z = a + ib,$ where
>
> What are you expecting?  What happens if you export the file to PDF?

Sorry, I assumed incorrectly that my question was self-explanatory. When
I export the file to PDF, the dollar characters are not regonized as
math delimiters.

Based on the manual I would have expected math delimiters. Referring
again to the manual: "single ‘$’ characters are only recognized as math
delimiters if the enclosed text contains at most two line breaks, is
directly attached to the ‘$’ characters with no whitespace in between,
and if the closing ‘$’ is followed by whitespace, punctuation or a
dash."

Since the equation in my example contains no line breaks, is directly
attached with no whitespace in between the equation and the dollar
signs, and the closing '$' is followed by whitespace, I would expect
math delimiter behaviour.

Removing all whitespace, that is, $z=a+ib,$ does not help.

> By the way, you might be interested in the following configuration
> snippet which makes org insert \(\) when you type a single $ (and a $
> if you type 2 of them in a row).

That is a nice little tool.

I have gotten used to writing '\(' and '\)' instead of '$' for a long
time. I was doing it for the millionth time and decided to take a look
at what the manual says. Hence this post.

Hope this clarifies my question.

Jarmo

[O] Latex single dollar math delimiter question

[Jarmo Hurri]

Greetings.

Org manual says that

To avoid conflicts with currency specifications, single ‘$’ characters
are only recognized as math delimiters if the enclosed text contains at
most two line breaks, is directly attached to the ‘$’ characters with no
whitespace in between, and if the closing ‘$’ is followed by whitespace,
punctuation or a dash.

Can someone explain why the single '$' characters below are not
recognized as math delimiters?

a /complex number/ $z = a + ib,$ where

Thanks in advance.

Jarmo

Re: [O] BUG in ob-scheme WAS: Re: Babel: verbatim results yield a table

[Jarmo Hurri]

Greetings again.

"Berry, Charles"  writes:

>> The org manual states that in the :results header argument of a block
>> 
>> verbatim Interpret literally and insert as quoted text. Do not create a
>> table. Usage example: :results value verbatim
>
> Unfortunately, `org-babel-scheme--table-or-string' does not honor
> :results verbatim. :-(

I wrote a patch for this before realizing that it had already been fixed
in the master branch (I was running the stable branch).

This should teach me a lesson again... :-)

Jarmo

Re: [O] Org src blocks and multiline macros

[Jarmo Hurri]

"Berry, Charles"  writes:

> ob-org does not provide for variables AFAICS. 

I have been trying to advocate for multiline macros for years, because
those are the _only_ thing I am really missing in org, again and
again. For example, right now I am writing teaching material where I
need to reuse certain parametrised org snippets across multiple files. I
_could_ use noweb. I _could_ use elisp code. But having a tool similar
to \newcommand in Latex would be so useful that every once in a while I
find myself bringing it up again.

The latest idea was to introduce variables into org blocks in hope it
would implement the desired functionality

> But using emacs-lisp with a :results drawer to render the output as
> org should help:
>
> #+header: :results drawer :exports results
> #+begin_src emacs-lisp :var val1="foo" :var val2="bar" 
>(concat "Currently this gives me ~" val1 val2 "~ indeed!")
> #+END_SRC
>
> #+RESULTS:
> :results:
> Currently this gives me ~foobar~ indeed!
> :end:

Ok, this will work too. But my real document string contains multiple
paragraphs, org lists etc. In terms of readability and maintainability,
embedding that text as an argument in an elisp call is not a very clean
solution.

> BTW, if you really do need a long or multiline MACRO, there is the
> possibility of using an `eval' style macro with a custom elisp
> function. e.g.
>
> #+MACRO: longish-macro (eval (my-really-long-macro-def $1 $2 $3))
>
> (info "(org) Macro Replacement")
>
> But this carries the burden of having to defun
> `my-really-long-macro-def' before exporting your document.

Yes, this too will work, with similar reservations as in the previous
case.

Thanks for all the tips!

Jarmo

Re: [O] BUG in ob-scheme WAS: Re: Babel: verbatim results yield a table

[Jarmo Hurri]

"Berry, Charles"  writes:

>> The org manual states that in the :results header argument of a block
>> 
>> verbatim Interpret literally and insert as quoted text. Do not create a
>> table. Usage example: :results value verbatim
>
> Unfortunately, `org-babel-scheme--table-or-string' does not honor
> :results verbatim. :-(

Thanks, I did not have the guts to call it a bug.

I'll see if I could provide a patch for this later.

Thanks.

Jarmo

Re: [O] Org src blocks and multiline macros

[Jarmo Hurri]

>> I am once again facing a situation where I would like to define a
>> multiline org macro.
>
>
> I'm not sure what that means, but based on your example a different
> solution might work for you.
>
> 2. If not, could we have this feature? This would give us immediate
>>multiline macros in the following style, where referring to the value
>>of the variable could be done macro-style.
>>
>> #+HEADER: :var val1=foo
>> #+BEGIN_SRC org :var val2=" bar"
>>   Currently this gives me nothing but {{{val1}}}{{{val2}}}.
>> ...
>>
>
> Org macros don't get evaluated inside src blocks as far as I know. But
> Noweb might help you. Look for this feature in Org manual. I use Noweb as
> "macros for src blocks".

Yep, that will give me something similar:

#+name: val1
#+BEGIN_SRC org :exports none
foo
#+END_SRC

#+name: val2
#+BEGIN_SRC org :exports none
bar
#+END_SRC

#+BEGIN_SRC org :noweb yes
  Currently this gives me ~<><>~ indeed!
#+END_SRC

Compared to multiline macros, though, having to (re)define bunch of src
blocks for variables does seem like an overkill.

BTW, does anyone know how I could enforce the standard
Org-interpretation of '~' in the resulting, exported Org.

Jarmo

[O] Babel: verbatim results yield a table

[Jarmo Hurri]

Greetings.

The org manual states that in the :results header argument of a block

verbatim Interpret literally and insert as quoted text. Do not create a
 table. Usage example: :results value verbatim

The quote above is from https://orgmode.org/manual/results.html

Given this description, I am trying to understand the result below from
a Scheme snippet (this is an exercise in the good old SICP). In
particular, why is the table created from the (nested) list?

Jarmo

   #+BEGIN_SRC scheme :exports both :results value verbatim
 (define (deep-reverse lst)
   (define (deep-iter lst result)
 (if (null? lst)
 result
 (let ((first (car lst)) (rest (cdr lst)))
   (deep-iter rest
  (cons (if
 (pair? first)
 (deep-reverse first)
 first)
result)
   (deep-iter lst '()))

 (deep-reverse (list (list 1 2 3 4) (list (list 5 6) 7 8)))
   #+END_SRC

   #+RESULTS:
   | 8 | 7 | (6 5) |   |
   | 4 | 3 | 2 | 1 |

[O] Org src blocks and multiline macros

[Jarmo Hurri]

Greetings.

I am once again facing a situation where I would like to define a
multiline org macro. If my memory is not failing me (it might well be),
this is not possible.

So this lead me to consider the use of Org source blocks in Babel. Which
might well be a discussion I have had here before, see the reference to
the state of my memory above.

1. Is it now possible to pass variables to these blocks?

2. If not, could we have this feature? This would give us immediate
   multiline macros in the following style, where referring to the value
   of the variable could be done macro-style.

#+HEADER: :var val1=foo
#+BEGIN_SRC org :var val2=" bar" 
  Currently this gives me nothing but {{{val1}}}{{{val2}}}.

  This property would really help me structure some org documents in a
  sensible way when common parts can be reused.
#+END_SRC

Jarmo

Re: [O] Latex preview foreground color problem

[Jarmo Hurri]

Eric S Fraga  writes:

> On Monday, 30 Jul 2018 at 12:43, Jarmo Hurri wrote:
>> In my emacs config file I now have:
>>
>> (plist-put org-format-latex-options :foreground "white")
>> (plist-put org-format-latex-options :scale 2)
>
> This works for me but in the context that I also change the background
> to black (which does not necessarily match my Emacs background...).  Try
> that just to see?  It may be a LaTeX issue.

This seems to be a compatibility issue with the forest package in
Latex. The problem is demonstrated and explained in the org file
below. I don't know yet what the solution is.

Jarmo

# -

#+LATEX_HEADER: \usepackage{forest}

* \LaTeX{} fragments: package ~forest~ confuses foreground color setting 
  Interestingly enough, the foreground color set by
  #+BEGIN_SRC elisp
  (plist-put org-format-latex-options :foreground "White")
  #+END_SRC
  does /not/ change the foreground color in this simple invariant
  equation \[ ab^n = ab\cdot b^{n-1} \] if ~usepackage{forest}~ is
  included in \LaTeX{} header. When package ~forest~ is not used,
  setting the color works just fine.

  To make things a bit more complicated, after commenting or
  uncommenting the ~LATEX_HEADER~ line, you need to remove the
  contents of directory ~ltximg~ in the working directory to see the
  difference, because the system caches the generated images of the
  equations there.

[O] Latex preview foreground color problem

[Jarmo Hurri]

Greetings.

Previewing Latex fragments is one cool feature. However, I have one
problem tailoring it to my use.

In my emacs config file I now have:

(plist-put org-format-latex-options :foreground "white")
(plist-put org-format-latex-options :scale 2)

These seem to set the correct properties, because my value of
org-format-latex-options is

(:foreground "white" :background default :scale 2 :html-foreground "Black" 
:html-background "Transparent" :html-scale 1.0 :matchers
 ("begin" "$1" "$" "$$" "\\(" "\\["))

The scale factor property works just fine: I get a larger
preview. Unfortunately changing foreground has no effect. The default
black foreground - which I still get - is pretty useless for me, because
my default background in buffers is dark blue.

Any tips?

Jarmo