Bug: org-plot gives Invalid function error

[ian martins]

I went to test the "Refresh inline" patch [1] and found that org-plot is
broken for me. it
seems to have broken in 1ac45d76e. I tested with =emacs -Q= (but loaded
Org from master and gnuplot.el manually).  I was running the example from
 the doc [2]. I tested on linux and mac, both using emacs 26.3, and got the
same result.

The error message is:

org-plot/gnuplot: Invalid function: (dump-func (plist-get type
:data-dump))

But if I manually load =org-plot.el= it doesn't give that error, but
still doesn't produce a plot.  I'm not sure what manually loading
=org-plot.el= does since I'd just done a "make clean; make" and restarted.

In the second case (after manually loading =org-plot.el=), this is what is
in
the *gnuplot* buffer:

Terminal type is now 'qt'
gnuplot> reset
gnuplot> set term GNUTERM

Terminal type is now 'qt'
Options are '0 font "Sans,9"'
gnuplot>
gnuplot> set title 'Citas'
gnuplot> set yrange [0:]
gnuplot> set yrange [0:]
gnuplot> set datafile separator "\t"
gnuplot> plot '/tmp/org-plotiPs0To' using 1:3 with histograms title
'H-index'
 warning: Skipping data file with no valid points

 ^
 x range is invalid

this is the data file:

"Chile" 257.72 21.39
"Leeds" 165.77 19.68
"Sao Paolo" 71.00 11.50
"Stockholm" 134.19 14.33
"Morelia" 257.56 17.67

I'll try to look into it more later.

[1] https://orgmode.org/list/87r1j0mg56@gmail.com/
[2] https://orgmode.org/manual/Org-Plot.html#Org-Plot

Re: [PATCH] Async session eval (2nd attempt)

[ian martins]

I gave this a try and it works for me. One thing I noticed is that if you
run a call asynchronously, the final result ends up under the source block
instead of the call.  In the example below both RESULTS were written after
I ran the call.

#+name: test-call
#+begin_src python :results output
  import time
  time.sleep(5)
  print("done")
#+end_src

#+RESULTS: test-call
: done

#+call: test-call() :session :async

#+RESULTS:
: 70e844920752b3411170716dc450c50f


On Sun, Apr 25, 2021 at 3:06 AM Jack Kamm  wrote:

> Hi Timothy,
>
> > This is moving at a glacial pace, but I'd love to see this merged ---
> > there's clearly a lot of interest in this from the community if not
> > within this mailing list (ob-async which is more limited has 250 stars
> > on GitHub).
>
> Yes, this has taken far too long -- sorry about that.
>
> There have been a few things going on in my life recently, among them a
> job change. I am in the process of trying to get my FSF copyright forms
> approved at my new job. I think this will eventually happen, but the
> process is moving slowly.
>
> My last update on this thread was shortly before changing jobs, and I
> decided not to merge until I was sure I'd be able to stick around to
> maintain it.
>
> If someone is willing to apply the final tweaks and help with maintenance
> of this functionality, please go ahead and merge this in. Otherwise, I'll
> merge this as soon as I've got my paperwork approved and am back in action.
>
> Jack
>
>

Re: [PATCH] ob-java: Allow import to end with asterisk

[ian martins]

On Sat, Apr 24, 2021 at 11:44 PM Timothy  wrote:

>
> This was not marked as applied on updates.orgmode.org.
> Doing so with the X-Woof-Patch header.
>
> ian martins  writes:
>
> > Thanks. And thanks for taking the time to fix issues that you find. It
> > continues to improve because of your contributions.
> > The patch looks good. Applied.
>

Thanks for fixing this. I re-read the woof documentation and realized I
needed to put "Applied" at the beginning of the line.

if anyone is curious, to save you a search, the doc is here:
https://github.com/bzg/woof#basic-usage

Re: Maintaining babel packages — a list of packages that need help?

[ian martins]

There's a list of languages here [1]. It looks like someone helpfully added
maintainers to the table. You could find languages without a listed
maintainer there and then check the header of the source file [2] to be
sure there's no current maintainer.

[1] https://orgmode.org/worg/org-contrib/babel/languages/index.html
[2] https://code.orgmode.org/bzg/org-mode/src/master/lisp

On Thu, Apr 22, 2021 at 1:14 AM Dr. Arne Babenhauserheide 
wrote:

>
> Timothy  writes:
> > As far as I know the only call for help maintaining Org has been with
> > babel packages. Otherwise you would have seen me volunteering :P I'd
> > like to do more if I get the opportunity.
>
> I’m currently in the process of enabling myself to contribute. Do we
> have a list of babel-packages that need maintenance? This is also
> something I’m personally interested in, because I use babel a lot,
> including in multi-language workflows.
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
>

Re: Concerns about community contributor support

[ian martins]

On Wed, Apr 21, 2021 at 9:49 PM Tim Cross  wrote:

>
> ian martins  writes:
>
> > On Wed, Apr 21, 2021 at 3:45 PM Tim Cross  wrote:
> >
> >  Responding to essentially just flag you have seen the patch message
> >  really only adds noise and may even 'drown out' those responses which
> >  add real 'value' to any discussion. I also doubt that asking people to
> >  do this would actually result in any actual change of behaviour by
> >  subscribers.
> >
> > Timothy said there were 25 patches without response and the list goes
> back six months, so we're only talking about 50 emails per year.
>
> That assumes there is a single 'owner' who accepts the responsibility to
> respond to every patch submitted.
>

Why does it? If some individual notices that some patch was submitted but
hasn't gotten a response, that person can send a "thanks for submitting.
probably maintainers don't use that feature." And someone else could check
Woof every three or six months, if so inclined. It doesn't have to be
anybody's job, and it doesn't have to be limited to some predesignated
group.

Having someone respond to the author of a patch and provide some
> meaningful feedback would be great, but I don't see how that can happen
> in a project which is already stretched and with limited resources.
> There has already been multiple messages requesting additional help and
> for volunteers willing to put in the time needed to maintain parts of
> org mode. Adding to that workload isn't going to help.
>

I don't see how this adds to the workload in a significant way, but also
couldn't this be the solution to that problem? Instead of ignoring
potential future contributors we could encourage and welcome them. Maybe we
don't have to be constrained by our current limit on resources.


> To some extent, if someone submits a
> patch and hears nothing, either they have failed to clearly explain what
> the patch does (and therefore did not tweak any interest) or it is a
> patch to introduce functionality which is of low interest to community
> participants.
>

But if they hear nothing, how are they to know which was the problem? And
if it was their first contact, how should they know the problem is one of
the things you listed instead of any number of reasons one can imagine that
no one is talking to them?

Re: Concerns about community contributor support

[ian martins]

On Wed, Apr 21, 2021 at 3:45 PM Tim Cross  wrote:

> Responding to essentially just flag you have seen the patch message
> really only adds noise and may even 'drown out' those responses which
> add real 'value' to any discussion. I also doubt that asking people to
> do this would actually result in any actual change of behaviour by
> subscribers.
>

Timothy said there were 25 patches without response and the list goes back
six months, so we're only talking about 50 emails per year.

Re: Concerns about community contributor support

[ian martins]

On Wed, Apr 21, 2021 at 9:27 AM Eric S Fraga  wrote:

>
> On Wednesday, 21 Apr 2021 at 12:55, ian martins wrote:
> > 1. A patch looks useful to me, but I feel I don't know if it's a good
>
> [...]
>
> >"Thanks for submitting this. I'd use it.  Hopefully a maintainer
> >will take a look."
>
> Ian,
>
> I think you will find that a few of us do post answers like this every
> now and again.  I know that I do.
>

I didn't mean to imply that you or anyone else never does this. I actually
don't do it myself, and on reflection I believe it is for the reasons I
listed above (a patch may look helpful but I don't know for sure that it'll
be good overall, or it applies to a part of the code that I've not looked
at). I thought others might have the same reasons for not responding.

The lack of answers to cases 2 & 3 are essentially showing a lack of
> interest which is basically an (implicit) answer as well.  It may seem
> dismissive but, given the volume of email some of us have to deal with
> in our day job, it's just reality, I would suggest, without it meaning
> to be judgemental in any way.
>

Lack of interest /is/ an implicit answer. The question is if that is a good
way to answer. I agree with Timothy that ignoring newcomers' first attempt
at contribution is an effective way to drive people away. Is that worth it
in order to reduce email?

Re: Concerns about community contributor support

[ian martins]

Timothy, thanks for raising this. I agree with everything you've said
in this thread. I think it may be a hard problem to solve, but maybe
we can start by just trying to improve. To be clear the problem I'm
talking about is that potential contributors sometimes receive no
response from the list.


Maybe it could help to normalize somewhat generic responses.  Here are
some possible situations where we might not respond to a patch
submission, followed by a potential response we might consider:

1. A patch looks useful to me, but I feel I don't know if it's a good
   idea for org in general, or maybe I think it is but I cannot apply the
   patch because (I'm not a maintainer, I don't have elisp experience, I
   haven't signed the copyright release, etc)

   "Thanks for submitting this. I'd use it.  Hopefully a maintainer
   will take a look."

2. A patch does not look useful to me, but I can see how it may be useful
   to someone else and it was posted a while ago and no one has commented
   yet.

   "Thanks for submitting this. It looks like this affects an org
   feature that not many of us use.  Sorry, but it might not get much
   attention."

3. A patch does not look useful to me, and can't imagine how it is useful
   in any context.

   "What is your use case?"


These trite responses may be seen as mailing list noise, but I don't
think so. They assure the patch submitter that their patch has been
seen and at least for (1) they signal to maintainers that the patch
would be useful to somebody.

There are volunteer maintainers for the codebase, and volunteers who
help with the mailing list.  Maybe someone who wants to help with this
could check Bark once in a while and respond to submissions that have
been missed or post them to the list to put them in front of everyone
again.

Re: header-args property

[ian martins]

On Thu, Apr 1, 2021 at 4:23 AM Michael Gauland  wrote:

> When I export, the result of the code block is "X is Hello", but when I
> use C-c
> C-c to evaluate the block in emacs, I get "X is"--the variable isn't
> defined.
>

This works for me on org 9.4.

I had trouble getting a file-level property to work across source blocks
before, but it worked in a property drawer. I thought this was going to be
that case, but I guess not. This seemed to work.

Re: Babel: Programmatically evaluate a heading and subtrees?

[ian martins]

Can you use noweb? In the example below, if you run the top code block
babel will run the two that follow.

A drawback is that you have to redefine variables, but it might be a
benefit, since the individual blocks could be set with test data and
the "main driver" could point to real data.
---

#+begin_src elisp :results output :noweb yes :var data=data1
  <>
  <>
#+end_src

#+RESULTS:
: called fun1: some data
: called fun2

#+name: data1
some data

#+name: fun1
#+begin_src elisp :var data=data1
(princ (format "called fun1: %s" data))
#+end_src

#+name: fun2
#+begin_src elisp
(princ "called fun2")
#+end_src

On Sat, Feb 20, 2021 at 2:11 PM Nathan Neff  wrote:
>
> Hello all,
>
> I have some code like this:
>
> * Heading 1
>
> # code block name:FOO
>
> ** Subheading 1
>
> # code block
>
> ** Subheading 2
>
> # code block
>
> I find that I often want to evaluate the code in Heading 1 and its 
> subheadings.
>
> Currently, I navigate to Heading 1 and then use org-babel-execute-subtree
>
> I see that there's a function called org-babel-goto-named-src-block, so I 
> think
> I could write a small function to jump to FOO in Heading 1 and then run 
> execute subtree
> and then jump back to my previous location in Emacs.
>
> Is there a more programmatic or built-in way?  For example:
> org-babel-execute-block-and-subheadings FOO
>
> Thanks,
> --Nate

Re: [PATCH] ob-java: Allow import to end with asterisk

[ian martins]

Thanks. And thanks for taking the time to fix issues that you find. It
continues to improve because of your contributions.
The patch looks good. Applied.

On Thu, Jan 28, 2021 at 3:04 PM John Herrlin  wrote:
>
>
> ian martins  writes:
>
> >> I found this case:
> >> And it seems to me that the import regex dont see the asterisk.
> >>
> >> I attached a possible patch.
> >
> > Thanks again, John.  You're right the regex is missing the asterisk
> > include. Thanks for the patch fixing. This works but it will add
> > redundant includes if the source block includes something that is also
> > in the list of classes to automatically include.
> >
> > for example, this:
> >
> > #+begin_src java :results value
> >   import java.util.*;
> >   return "test";
> > #+end_src
> >
> > will end up pulling in
> >
> > import java.util.List;
> > import java.util.*;
> >
> > It wouldn't hurt anything, but could probably be prevented by changing
> > the regexp in =org-babel-java--import-maybe= to look for asterisk as
> > well as =class=.  Do you feel like updating the patch?
> >
> > [1] https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-java.el#L314
>
> Here is an updated patch. It seems to work on my cases.
>
> Of topic, I am very happy with the latest updates on ob-java and I think
> it works really good! Thanks for the awesome work Ian!
>
> Stay safe!
>

Re: [PATCH] ob-java: Allow import to end with asterisk

[ian martins]

> I found this case:
> And it seems to me that the import regex dont see the asterisk.
>
> I attached a possible patch.

Thanks again, John.  You're right the regex is missing the asterisk
include. Thanks for the patch fixing. This works but it will add
redundant includes if the source block includes something that is also
in the list of classes to automatically include.

for example, this:

#+begin_src java :results value
  import java.util.*;
  return "test";
#+end_src

will end up pulling in

import java.util.List;
import java.util.*;

It wouldn't hurt anything, but could probably be prevented by changing
the regexp in =org-babel-java--import-maybe= to look for asterisk as
well as =class=.  Do you feel like updating the patch?

[1] https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-java.el#L314

Re: [PATCH] ob-java, a proposal on import improvement

[ian martins]

It's no problem. Didn't mean to rush you. Thanks again for the patch. Applied.

On Sat, Jan 16, 2021 at 10:32 AM John Herrlin  wrote:
>
>
> Sorry for latency, 9to5 been killing it. Thx for the feedback, make
> sense! Here is a new patch with the improvements.
>
>
>
> ian martins  writes:
>
> > John, would you mind if I go ahead and make the change I mentioned and
> > push it with you as the author?
> >
> > On Tue, Jan 12, 2021 at 7:00 AM ian martins  wrote:
> >>
> >> On Sun, Jan 10, 2021 at 3:55 PM John Herrlin  wrote:
> >> > ian martins  writes:
> >> > > I think the problem was that I was missing static
> >> > > imports, which you fixed in the first chunk of your patch. I don't
> >> > > think the rest of the change is necessary. Could you revert the other
> >> > > chunks and re-test?
> >> >
> >> > Thats looks correct! Thanks!
> >> >
> >> > Here is a patch with the regexp fix.
> >>
> >> That's great. One small change, though. This only allows for a single
> >> space between "import" and "static" so if someone were to put in two
> >> it wouldn't work. I actually did the same thing in an earlier version
> >> and it caused a problem. Since then I went to =(1+ space)=
> >> everywhere. Could you also move the part that you're adding down to
> >> the next line. It's not that the line is too long, but it keeps it to
> >> one thing per line.
> >>
> >> The commit message is fine, but the first line shouldn't end in a period.
> >>
> >> ref: https://orgmode.org/worg/org-contribute.html#commit-messages

Re: [PATCH] ob-java, a proposal on import improvement

[ian martins]

John, would you mind if I go ahead and make the change I mentioned and
push it with you as the author?

On Tue, Jan 12, 2021 at 7:00 AM ian martins  wrote:
>
> On Sun, Jan 10, 2021 at 3:55 PM John Herrlin  wrote:
> > ian martins  writes:
> > > I think the problem was that I was missing static
> > > imports, which you fixed in the first chunk of your patch. I don't
> > > think the rest of the change is necessary. Could you revert the other
> > > chunks and re-test?
> >
> > Thats looks correct! Thanks!
> >
> > Here is a patch with the regexp fix.
>
> That's great. One small change, though. This only allows for a single space 
> between "import" and "static" so if someone were to put in two it wouldn't 
> work. I actually did the same thing in an earlier version and it caused a 
> problem. Since then I went to =(1+ space)= everywhere. Could you also move 
> the part that you're adding down to the next line. It's not that the line is 
> too long, but it keeps it to one thing per line.
>
> The commit message is fine, but the first line shouldn't end in a period.
>
> ref: https://orgmode.org/worg/org-contribute.html#commit-messages

Re: [PATCH] ob-java, a proposal on import improvement

[ian martins]

 <https://orgmode.org/worg/org-contribute.html#commit-messages>On Sun, Jan
10, 2021 at 3:55 PM John Herrlin  wrote:
> ian martins  writes:
> > I think the problem was that I was missing static
> > imports, which you fixed in the first chunk of your patch. I don't
> > think the rest of the change is necessary. Could you revert the other
> > chunks and re-test?
>
> Thats looks correct! Thanks!
>
> Here is a patch with the regexp fix.

That's great. One small change, though. This only allows for a single space
between "import" and "static" so if someone were to put in two it wouldn't
work. I actually did the same thing in an earlier version and it caused a
problem. Since then I went to =(1+ space)= everywhere. Could you also move
the part that you're adding down to the next line. It's not that the line
is too long, but it keeps it to one thing per line.

The commit message is fine, but the first line shouldn't end in a period.

ref: https://orgmode.org/worg/org-contribute.html#commit-messages

Re: [PATCH] ob-java, a proposal on import improvement

[ian martins]

> I can’t give an informed opinion about the patch, but the example looks
> great! I did not know that Java support in org-babel is that good.

Thanks. Yes, ob-java got an update with org 9.4.

Re: [PATCH] ob-java, a proposal on import improvement

[ian martins]

On Fri, Jan 8, 2021 at 11:28 AM John Herrlin  wrote:

> I would like to combine imports from header-args with imports from a
> source block.
> ...
> I didnt get the to work so I made a patch.

John, Sorry that wasn't working. Thanks for investigating and
submitting a fix.  I think the problem was that I was missing static
imports, which you fixed in the first chunk of your patch. I don't
think the rest of the change is necessary. Could you revert the other
chunks and re-test?

This works for me using master, and your patch produces nearly the
same code (only import order differs):

#+begin_src java :results output :imports java.util.HashMap
  import java.util.Map;

  Map hash = new HashMap<>();
  hash.put("one", 1);
  hash.put("two", 2);
  System.out.println(hash);
#+end_src

Re: consistent behavior across babel languages

[ian martins]

On Thu, Nov 26, 2020 at 9:42 AM Neil Jerram  wrote:

> Wonderful, thank you.  I have been thinking it would be nice to have a test 
> suite along these lines, but detailed doc like this is more feasible and 
> maintainable.

A test suite is a good idea as a next step to protect correct
behaviors. I want to first look at actual behaviors and get agreement
on correct behaviors first. On the other hand, each of the language's
test suites should cover the same ground so a separate test suite may
not make sense.

> When time permits I will work on adding Scheme to this page.

Great, thanks!

> FWIW, I did not understand the "functional" and "scripting" terms that you 
> use on this page.
>
> I've understood now, from 
> https://orgmode.org/worg/org-contrib/babel/intro.html, that you mean 
> "results: value" and "results: output".  For me it would be better if you 
> said that instead of "functional" and "scripting", as the former is what I 
> can actually type in my Org files.

yes, it's in the manual as well [1], but I agree that alternating
between two sets of terms here is unnecessarily confusing. Will
change.

[1] https://orgmode.org/manual/Results-of-Evaluation.html#Results-of-Evaluation

Re: consistent behavior across babel languages

[ian martins]

On Wed, Nov 25, 2020 at 2:06 AM Tim Cross  wrote:
>
> I will try to allocate time on the weekend to
> review what you have and see if there are any I know of which you have
> not included.

That would be great.

On Wed, Nov 25, 2020 at 2:39 PM Tom Gillespie  wrote:
>
> Since there are so many different features that
> a babel language implementation can support I don't want to try to put
> them all in one table quite yet but I think it may be helpful to do so
> eventually. Until that time does it make sense to add new sections to
> the file that cover specific features? For example I have tests on
> TRAMP support and/or support for execution via a remote session that I
> would like to add from my internal notes. Can I add it as a new
> section?

Yes, definitely. My plan is to add sections for major features or
feature groups and have a table for each section, and when that stops
working to think of something else. I am planning a section for
variables focusing on passing lists and tables which will probably
look a lot like the section on returning list and tables. There should
definitely be a section on TRAMP.

consistent behavior across babel languages

[ian martins]

Something I've found challenging is the inconsistency between babel
languages. It makes it difficult for a babel user to get a source
block to do what they want, or for a babel developer to even know what
correct behavior is.

I'm not sure if anything can be done since changes will likely break
existing behavior, but it's good to at least know what the rule is and
where the exceptions to the rule are. To that end I started a page on
worg [1] to document current behavior for actions taken across babel
languages.

[1] https://orgmode.org/worg/org-contrib/babel/languages/lang-compat.html

org-plot line colors

[ian martins]

I wanted to change line colors but didn't find a way. Is there a way?

This almost works:

#+PLOT: ind:1 deps:(2) set:"set style line 1 lc rgbcolor 'blue'"

but it needs a `linestyle' set for each line, like this:

plot '/tmp/org-plotiLccTT' using 1:2 with lines title 'some title' ls 1

note the `ls n' at the end. I think this is safe since there are
default linestyle settings, so long as n doesn't exceed the number of
linestyles available for the mode it doesn't matter if the plot config
defines them.

also note that I used single quotes for the color name in the plot
config. I don't think org allows escaped quotes in headers. luckily
gnuplot allows single quotes.

Re: [PATCH] org-plot abstractions and extension

[ian martins]

On Sat, Oct 24, 2020 at 2:21 PM TEC  wrote:
> Sounds good then. I don't expect the changes to compromise any
> existing
> functionality.

I tested these patches and didn't have a problem. I didn't go out of
my way to see what changed and test it, but org-plot didn't break for
what I was doing.

I was hoping to be able to change line colors, but didn't find a way.
I'll ask about it in another thread.

Re: default :results

[ian martins]

On Sat, Nov 14, 2020 at 5:27 AM ian martins  wrote:
>
> On Wed, Nov 11, 2020 at 3:04 AM Bastien  wrote:
> >
> > The default for ob-shell execution was to use the output, not the
> > value.  Then we had a long discussion, leading to this:
> >
> > - The default (no :result) is to display the functional value
> >
> > - For some languages, it may break expectations, so in this case we
> >   allow a variable that let the default (no :result) use the output
> >   instead of the functional value.
> >
> >   This is what is being done for ob-shell.el where we have
> >   `org-babel-shell-results-defaults-to-output' set to `t'.
> >
> > See https://orgmode.org/list/877dt5trjr@bzg.fr/ for the conclusion
> > of the discussion.
>
> I agree with your reasoning. I already reverted the behavior, but
> Instead of adding a `org-babel-java-results-defaults-to-output
> variable' I set the default in `org-babel-default-header-args:java'.
> It was better because it didn't add a new variable, but worse because
> it isn't customizable. Should I change it?

shortly after sending this I reverted another change I'd made to
default behavior by setting it in
`org-babel-default-header-args:java'. Another benefit of doing it here
is that this variable becomes a list of ways in which a language
doesn't follow normal babel default conventions, making it easy to
find.

Re: [PATCH] ob-java

[ian martins]

On Sat, Nov 14, 2020 at 6:48 AM Jarmo Hurri  wrote:
>
> >> > 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
> >>

This should be fixed with 93087e0b3a. Thanks for reporting, and sorry
I missed your first email. I found it. It went to spam for some
reason.

Also I added two sections to the doc: one that explains the current
defaults and tells how to change them [1], and another that explains
where source and class files go [2].

[1] 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html#orgb4194fe
[2] 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html#org0948fdf

Re: [PATCH] ob-java

[ian martins]

On Sat, Nov 14, 2020 at 6:48 AM Jarmo Hurri  wrote:
> 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.

It looks like you quoted a previous email there but I never saw it.

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.

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

I agree we should not change the default behavior, but I'm not sure
about data files. The run directory shouldn't change, just the place
where the files are written. when I run this block the java and
classfiles are written to my babel temp dir but it prints out the path
of the org file.

#+begin_src java :results output silent
System.out.println( System.getProperty("user.dir"));
#+end_src

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

I've not seen it documented, but the other babel languages I've used
write to the temp dir. Java is the only one I'm aware of that
defaulted to writing to the current directory.

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

Yes, you're right that is a change. The current behavior is documented
in ob-doc-java [1], but it isn't called out as a change in behavior.
This is because I didn't notice it as a change, or I'd have not done
it. These changes happened in part because I wrote ob-java in a
circuitous way. I first wrote ob-haxe (for the language haxe) based on
ob-C and ob-python and then made ob-java from it. When I wrote ob-haxe
I wasn't thinking about maintaining ob-java behaviour, and it wasn't
documented, and there weren't tests, so when I had a new ob-java it
wasn't easy to see what might have changed. It is very helpful that
you tested your existing source blocks and investigated changes.
Thanks for reporting. I'll bring back the old default behavior.

[1] 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html#org932f876

Re: default :results

[ian martins]

On Wed, Nov 11, 2020 at 3:04 AM Bastien  wrote:
>
> The default for ob-shell execution was to use the output, not the
> value.  Then we had a long discussion, leading to this:
>
> - The default (no :result) is to display the functional value
>
> - For some languages, it may break expectations, so in this case we
>   allow a variable that let the default (no :result) use the output
>   instead of the functional value.
>
>   This is what is being done for ob-shell.el where we have
>   `org-babel-shell-results-defaults-to-output' set to `t'.
>
> See https://orgmode.org/list/877dt5trjr@bzg.fr/ for the conclusion
> of the discussion.

I agree with your reasoning. I already reverted the behavior, but
Instead of adding a `org-babel-java-results-defaults-to-output
variable' I set the default in `org-babel-default-header-args:java'.
It was better because it didn't add a new variable, but worse because
it isn't customizable. Should I change it?

> Also see `org-babel-shell-results-defaults-to-output' docstring:
>
>   Let shell execution defaults to ":results output".
>
>   When set to t, use ":results output" when no :results setting
>   is set.  This is especially useful for inline source blocks.
>
>   When set to nil, stick to the convention of using :results value
>   as the default setting when no :results is set, the "value" of
>   a shell execution being its exit code.
>
> > And is this inconsistent behavior across languages something that
> > should be fixed? or is it intentional or at least not worth doing
> > anything about?
>
> What was suggested is to have a page on Worg listing the behavior of
> various packages regarding block execution.
>
> I started a section on https://orgmode.org/worg/library-of-babel.html
> with a table -- feel free to add more to this table.

Thanks, I will add to it. Would it be better for the table to be on
the languages [1] page? If so, I can move it when I update.

Also, there are two library of babel pages ([2], [3]) that appear to
serve the same purpose. I was thinking of merging them. Is that fine?

[1] https://orgmode.org/worg/org-contrib/babel/languages/index.html
[2] https://orgmode.org/worg/org-contrib/babel/library-of-babel.html
[3] https://orgmode.org/worg/library-of-babel.html

Re: [PATCH] ob-java.el: Allow for more whitespace

[ian martins]

On Thu, Nov 12, 2020 at 10:46 PM Kyle Meyer  wrote:
>
> ian martins writes:
>
> > Subject: [PATCH 2/2] ob-java.el: Allow for more whitespace in java code
> >
> > * lisp/ob-java.el (defconst *-re): Updated regexps to allow for more
> > whitespace in the content of java code blocks, and removed some
> > redundancies.
>
> Sorry, more change log nitpicking from me (which is even less fun to do
> than other nitpicking because I dislike the practice of including change
> logs in commit messages).

No problem. Gathering the list of changed names is easy (I use emacs).
I thought the long list would make the entry less useful, but I can
see how it makes it more searchable this way. Of course, people could
search the code diffs instead and then the commit logs could just be
written for people.

> Please name each variable in full.  Here's the relevant bit from the
> guidelines that Emacs's CONTRIBUTE points to:
>
> If you mention the names of the modified functions or variables,
> it’s important to name them in full.  Don’t abbreviate function or
> variable names, and don’t combine them.  Subsequent maintainers will
> often search for a function name to find all the change log entries
> that pertain to it; if you abbreviate the name, they won’t find it
> when they search.
>
> https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs
>
> We should probably link to that in worg's org-contribute.org.

Thanks for providing the reference. I'll add a link to worg if there isn't one.

> > * testing/lisp/test-ob-java.el (ob-java/simple-with-main-whitespace):
> > Added test case with lots of whitespace.
>
> Is this related to Jarmo's report at
> <https://orgmode.org/list/87o8k68w05@iki.fi>?  If so, it'd be good
> to include a Reported-by trailer as well as a link.

Yes. The updated patch includes Reported-by. That is just text in the
commit message, not a git option, right?

> > -(defconst org-babel-java--package-re 
> > "^[[:space:]]*package[[:space:]]+\\\([[:alnum:]_\.]+\\\);$"
> > +(defconst org-babel-java--package-re 
> > "^[[:space:]]*package[[:space:]]+\\\([[:alnum:]_\.]+\\\)[[:space:]]*;$"
> >"Regexp for the package statement.")
> > -(defconst org-babel-java--imports-re 
> > "^[[:space:]]*import[[:space:]]+\\\([[:alnum:]_\.]+\\\);$"
> > +(defconst org-babel-java--imports-re 
> > "^[[:space:]]*import[[:space:]]+\\\([[:alnum:]_\.]+\\\)[[:space:]]*;$"
> >"Regexp for import statements.")
> > -(defconst org-babel-java--class-re 
> > "^[[:space:]]*\\\(?:public[[:space:]]+\\\)?class[[:space:]]+\\\([[:alnum:]_]+\\\)[[:space:]]*\n?[[:space:]]*{"
> > +(defconst org-babel-java--class-re 
> > "^[[:space:]]*\\\(?:public[[:space:]]+\\\)?class[[:space:]]+\\\([[:alnum:]_]+\\\)[[:space:]]*{"
> >"Regexp for the class declaration.")
> > -(defconst org-babel-java--main-re "public static void 
> > main(String\\\(?:\\[]\\\)?[[:space:]]+[^ 
> > ]+\\\(?:\\[]\\\)?).*\n?[[:space:]]*{"
> > +(defconst org-babel-java--main-re 
> > "public[[:space:]]+static[[:space:]]+void[[:space:]]+main[[:space:]]*([[:space:]]*String[[:space:]]*.*[[:space:]]*)[[:space:]]*.*[[:space:]]*{"
> >"Regexp for the main method declaration.")
> > -(defconst org-babel-java--any-method-re "public .*(.*).*\n?[[:space:]]*{"
> > +(defconst org-babel-java--any-method-re 
> > "public[[:space:]]+.*[[:space:]]*([[:space:]]*.*[[:space:]]*)[[:space:]]*.*[[:space:]]*{"
> >"Regexp for any method.")
>
> Not speaking Java, I don't have anything actually valuable to say about
> this change, but I wouldn't complain if these regular expressions were
> switched over to rx (or at least tamed a bit in terms of line length).

Thanks for the suggestion. I hadn't seen `rx' before. It's beautiful.
I converted it. That was a joy.
From 4784ea1e926da014e30bbbaa241b3779a14119f4 Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Thu, 12 Nov 2020 05:18:48 -0500
Subject: [PATCH 2/2] ob-java.el: Allow for more whitespace in java code

* lisp/ob-java.el (org-babel-java--package-re)
(org-babel-java--imports-re, org-babel-java--class-re)
(org-babel-java--main-re, org-babel-java--any-method-re):
Updated regexps to allow for more whitespace in the content of java
code blocks.  Convert regexps to `rx' to improve clarity.
* testing/lisp/test-ob-java.el (ob-java/simple-with-main-whitespace):
Added test case with excessive whitespace.

Reported-by: Jarmo Hurri 
<https://orgmode.org/list/87o8k68w05@iki.fi>
---
 lisp/ob-java.el  | 35 ++-
 testing/lisp

[PATCH] ob-java.el: Allow for more whitespace

[ian martins]

Two patches are attached. One allows for more whitespace in java code
blocks. The other fixes a bug that would result in a main method being
wrapped in another main method.
From 9fbb5a436ebc007d19adc20fcee7ebf08e4aec3b Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Thu, 12 Nov 2020 05:09:11 -0500
Subject: [PATCH 1/2] ob-java.el: Do not wrap a main method in a main method

* lisp/ob-java.el (org-babel-expand-body:java): The code was checking
for existence of a class declaration before wrapping the content of
the code block in a main method, but it should be checking for
existence of a main method.
---
 lisp/ob-java.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index d8d4db852..92e873f0d 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -296,7 +296,7 @@ is simplest to expand the code block from the inside out."
   ;; wrap main.  If there are methods defined, but no main method
   ;; and no class, wrap everything in a generic main method.
   (goto-char (point-min))
-  (when (and (not (re-search-forward org-babel-java--class-re nil t))
+  (when (and (not (re-search-forward org-babel-java--main-re nil t))
  (not (re-search-forward org-babel-java--any-method-re nil t)))
 (org-babel-java--move-past org-babel-java--package-re) ; if package is defined, move past it
 (org-babel-java--move-past org-babel-java--imports-re) ; if imports are defined, move past them
-- 
2.25.1

From 19af495f4152cd7b8580ceab2a168182f44bedbb Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Thu, 12 Nov 2020 05:18:48 -0500
Subject: [PATCH 2/2] ob-java.el: Allow for more whitespace in java code

* lisp/ob-java.el (defconst *-re): Updated regexps to allow for more
whitespace in the content of java code blocks, and removed some
redundancies.

* testing/lisp/test-ob-java.el (ob-java/simple-with-main-whitespace):
Added test case with lots of whitespace.
---
 lisp/ob-java.el  | 10 +-
 testing/lisp/test-ob-java.el | 18 ++
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index 92e873f0d..d65176d4e 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -77,15 +77,15 @@ like javac -verbose."
   :package-version '(Org . "9.5")
   :type 'symbol)
 
-(defconst org-babel-java--package-re "^[[:space:]]*package[[:space:]]+\\\([[:alnum:]_\.]+\\\);$"
+(defconst org-babel-java--package-re "^[[:space:]]*package[[:space:]]+\\\([[:alnum:]_\.]+\\\)[[:space:]]*;$"
   "Regexp for the package statement.")
-(defconst org-babel-java--imports-re "^[[:space:]]*import[[:space:]]+\\\([[:alnum:]_\.]+\\\);$"
+(defconst org-babel-java--imports-re "^[[:space:]]*import[[:space:]]+\\\([[:alnum:]_\.]+\\\)[[:space:]]*;$"
   "Regexp for import statements.")
-(defconst org-babel-java--class-re "^[[:space:]]*\\\(?:public[[:space:]]+\\\)?class[[:space:]]+\\\([[:alnum:]_]+\\\)[[:space:]]*\n?[[:space:]]*{"
+(defconst org-babel-java--class-re "^[[:space:]]*\\\(?:public[[:space:]]+\\\)?class[[:space:]]+\\\([[:alnum:]_]+\\\)[[:space:]]*{"
   "Regexp for the class declaration.")
-(defconst org-babel-java--main-re "public static void main(String\\\(?:\\[]\\\)?[[:space:]]+[^ ]+\\\(?:\\[]\\\)?).*\n?[[:space:]]*{"
+(defconst org-babel-java--main-re "public[[:space:]]+static[[:space:]]+void[[:space:]]+main[[:space:]]*([[:space:]]*String[[:space:]]*.*[[:space:]]*)[[:space:]]*.*[[:space:]]*{"
   "Regexp for the main method declaration.")
-(defconst org-babel-java--any-method-re "public .*(.*).*\n?[[:space:]]*{"
+(defconst org-babel-java--any-method-re "public[[:space:]]+.*[[:space:]]*([[:space:]]*.*[[:space:]]*)[[:space:]]*.*[[:space:]]*{"
   "Regexp for any method.")
 (defconst org-babel-java--result-wrapper "\npublic static String __toString(Object val) {
 if (val instanceof String) {
diff --git a/testing/lisp/test-ob-java.el b/testing/lisp/test-ob-java.el
index e14975412..50d3ef5b0 100644
--- a/testing/lisp/test-ob-java.el
+++ b/testing/lisp/test-ob-java.el
@@ -128,6 +128,24 @@ public static void main(String args[]) {
 #+end_src"
 (should (string= "42" (org-babel-execute-src-block)
 
+(ert-deftest ob-java/simple-with-main-whitespace ()
+  "Hello world program that defines a main function with the square brackets after `args'."
+  (org-test-with-temp-text
+  "#+begin_src java :results output silent
+public
+static
+void
+main
+ (
+ String
+ args []
+ )
+{
+System.out.print(42);
+}
+#+end_src"
+(should (string= "42" (org-babel-execute-src-block)
+
 (ert-deftest ob-java/simple-with-class ()
   "Hello world program that defines a class."
   (org-test-with-temp-text
-- 
2.25.1

Re: [PATCH] ob-java

[ian martins]

That is true. I will make it less rigid.

On Mon, Nov 9, 2020 at 9:07 AM Jarmo Hurri  wrote:

>
> 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: Viewing link information

[ian martins]

There is a shortcut to copy the link here
. You could display it
in the same way.

On Fri, Oct 30, 2020 at 12:15 PM Russell Adams 
wrote:

> Are there other ways to view information about an org link that I
> don't list below?
>
>  - M-x org-insert-link, the prompts for link and description show the
>current values. Requires interacting with the prompts.
>
>  - Switch to fundamental mode
>
>  - M-x org-toggle-link-display
>
> Are there ways to see this information live while navigating? Maybe on
> the modeline, or messages?
>
> --
> Russell Adamsrlad...@adamsinfoserv.com
>
> PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/
>
> Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
>
>

Re: [PATCH] org-manual.org: Remove languages list and update worg link

[ian martins]

I pushed two days ago, but the manual hasn't updated yet. I guess it
doesn't update on git hooks like worg. is there a scheduled process or is
there something that must be done?

On Thu, Nov 5, 2020 at 11:03 PM Kyle Meyer  wrote:

> ian martins writes:
>
> > Subject: [PATCH] org-manual.org: Remove language list and fix Worg link
> >
> > * doc/org-manual.org: Remove the language list and fix the Worg link
> > since the languages page has moved.  Renumber footnotes.
> >
> > The language list in the manual is missing many languages.  Rather
> > than trying to keep the list up to date in two places that link to
> > each other, this removes the list from the manual which is updated
> > less frequently.  There were a few footnotes in the table, so this
> > also renumbers the remaining footnotes.
>
> Sounds like a good idea to me.
>
> > The languages page was moved in Worg to make it the index page in the
> > languages directory.  This updates the link in the manual to point to
> > its new location.
> > ---
> >  doc/org-manual.org | 103 +
> >  1 file changed, 38 insertions(+), 65 deletions(-)
> [...]
> > -[fn:160] Note that, for ~org-odd-levels-only~, a level number
> > +[fn:158] Note that, for ~org-odd-levels-only~, a level number
> >  corresponds to order in the hierarchy, not to the number of stars.
> >
> >  [fn:161] If you move entries or Org files from one directory to
>
> Hmm, the 158 to 161 jump after your renumbering caught my eye, but it
> looks like it's orthogonal to your changes.  There was a bad merge
> conflict resolution in 9410fbe06 that unlinked this definition from its
> reference (one of the two [fn:89]s).  I'll clean it up after your
> changes land.
>

Re: [PATCH] ob-java

[ian martins]

I'm sorry that happened. It must have been frustrating. If you executed a
code block and no result was added to the buffer, then there's a chance it
is fixed.

Let me know how it goes.

On Fri, Nov 6, 2020 at 12:21 AM Jarmo Hurri  wrote:

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

[ian martins]

Yes, that page is up to date. Actually, the page is new.

Are you using the latest? Were there any issues when you updated?

On Thu, Nov 5, 2020, 11:32 AM Jarmo Hurri  wrote:

>
> 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: [PATCH] org-manual.org: Remove languages list and update worg link

[ian martins]

Attached is an updated patch that renumbers footnotes since a few footnotes
were removed with the table.

On Wed, Nov 4, 2020 at 8:39 AM ian martins  wrote:

> The language list in the manual is missing many languages.  Rather
> than trying to keep the list up to date in two places that link to
> each other, this removes the list from the manual which is updated
> less frequently.
>
> The languages page was moved in Worg to make it the index page in the
> languages directory.  This updates the link in the manual to point to
> its new location.
>
From 539afdb50e146f6eaf55d67ae5dd240d8dba6ab3 Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Wed, 4 Nov 2020 08:32:12 -0500
Subject: [PATCH] org-manual.org: Remove language list and fix Worg link

* doc/org-manual.org: Remove the language list and fix the Worg link
since the languages page has moved.  Renumber footnotes.

The language list in the manual is missing many languages.  Rather
than trying to keep the list up to date in two places that link to
each other, this removes the list from the manual which is updated
less frequently.  There were a few footnotes in the table, so this
also renumbers the remaining footnotes.

The languages page was moved in Worg to make it the index page in the
languages directory.  This updates the link in the manual to point to
its new location.
---
 doc/org-manual.org | 103 +
 1 file changed, 38 insertions(+), 65 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ef2dad9ef..49b31e08d 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17925,35 +17925,8 @@ code block header arguments:
 #+cindex: source code, languages
 #+cindex: code block, languages
 
-Code blocks in the following languages are supported.
-
-#+attr_texinfo: :columns 0.25 0.25 0.25 0.20
-| Language   | Identifier| Language   | Identifier   |
-|+---++--|
-| Asymptote  | =asymptote=   | Lisp   | =lisp=   |
-| Awk| =awk= | Lua| =lua=|
-| C  | =C=   | MATLAB | =matlab= |
-| C++| =C++=[fn:142] | Mscgen | =mscgen= |
-| Clojure| =clojure= | Objective Caml | =ocaml=  |
-| CSS| =css= | Octave | =octave= |
-| D  | =D=[fn:143]   | Org mode   | =org=|
-| ditaa  | =ditaa=   | Oz | =oz= |
-| Emacs Calc | =calc=| Perl   | =perl=   |
-| Emacs Lisp | =emacs-lisp=  | Plantuml   | =plantuml=   |
-| Eshell | =eshell=  | Processing.js  | =processing= |
-| Fortran| =fortran= | Python | =python= |
-| Gnuplot| =gnuplot= | R  | =R=  |
-| GNU Screen | =screen=  | Ruby   | =ruby=   |
-| Graphviz   | =dot= | Sass   | =sass=   |
-| Haskell| =haskell= | Scheme | =scheme= |
-| Java   | =java=| Sed| =sed=|
-| Javascript | =js=  | shell  | =sh= |
-| LaTeX  | =latex=   | SQL| =sql=|
-| Ledger | =ledger=  | SQLite | =sqlite= |
-| Lilypond   | =lilypond=| Vala   | =vala=   |
-
-Additional documentation for some languages is at
-https://orgmode.org/worg/org-contrib/babel/languages.html.
+Code blocks in dozens of languages are supported.  See Worg for
+[[https://orgmode.org/worg/org-contrib/babel/languages/index.html][language specific documentation]].
 
 #+vindex: org-babel-load-languages
 By default, only Emacs Lisp is enabled for evaluation.  To enable or
@@ -18067,7 +18040,7 @@ for Python and Emacs Lisp languages.
 
 #+cindex: @samp{noweb-ref}, header argument
 Source code blocks can include references to other source code blocks,
-using a noweb[fn:144] style syntax:
+using a noweb[fn:142] style syntax:
 
 : <>
 
@@ -18578,7 +18551,7 @@ Org Tempo expands snippets to structures defined in
 ~org-structure-template-alist~ and ~org-tempo-keywords-alist~.  For
 example, {{{kbd(< s TAB)}}} creates a code block.  Enable it by
 customizing ~org-modules~ or add =(require 'org-tempo)= to your Emacs
-init file[fn:145].
+init file[fn:143].
 
 #+attr_texinfo: :columns 0.1 0.9
 | {{{kbd(a)}}} | =#+BEGIN_EXPORT ascii= ... =#+END_EXPORT= |
@@ -18658,7 +18631,7 @@ in the desired amount with hard spaces and hiding leading stars.
 To display the buffer in the indented view, activate Org Indent minor
 mode, using {{{kbd(M-x org-indent-mode)}}}.  Text lines that are not
 headlines are prefixed with virtual spaces to vertically align with
-the headline text[fn:146].
+the headline text[fn:144].
 
 #+vindex: org-indent-indentation-per-level
 To make more horizontal space, the headlines are shifted by two
@@ -18686,9 +18659,9 @@ use =STARTUP= keyword as follows:
 
 It is possible to use hard spaces to achieve the ind

[PATCH] org-manual.org: Remove languages list and update worg link

[ian martins]

The language list in the manual is missing many languages.  Rather
than trying to keep the list up to date in two places that link to
each other, this removes the list from the manual which is updated
less frequently.

The languages page was moved in Worg to make it the index page in the
languages directory.  This updates the link in the manual to point to
its new location.
From a02c13a1fcf2b3d023bb5ef464245d600f4eaf30 Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Wed, 4 Nov 2020 08:32:12 -0500
Subject: [PATCH] org-manual.org: Remove language list and fix Worg link

* doc/org-manual.org: Remove the language list and fix the Worg link
since the page has moved.

The language list in the manual is missing many languages.  Rather
than trying to keep the list up to date in two places that link to
each other, this removes the list from the manual which is updated
less frequently.

The languages page was moved in Worg to make it the index page in the
languages directory.  This updates the link in the manual to point to
its new location.
---
 doc/org-manual.org | 31 ++-
 1 file changed, 2 insertions(+), 29 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index ef2dad9ef..2a6ef6f16 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -17925,35 +17925,8 @@ code block header arguments:
 #+cindex: source code, languages
 #+cindex: code block, languages
 
-Code blocks in the following languages are supported.
-
-#+attr_texinfo: :columns 0.25 0.25 0.25 0.20
-| Language   | Identifier| Language   | Identifier   |
-|+---++--|
-| Asymptote  | =asymptote=   | Lisp   | =lisp=   |
-| Awk| =awk= | Lua| =lua=|
-| C  | =C=   | MATLAB | =matlab= |
-| C++| =C++=[fn:142] | Mscgen | =mscgen= |
-| Clojure| =clojure= | Objective Caml | =ocaml=  |
-| CSS| =css= | Octave | =octave= |
-| D  | =D=[fn:143]   | Org mode   | =org=|
-| ditaa  | =ditaa=   | Oz | =oz= |
-| Emacs Calc | =calc=| Perl   | =perl=   |
-| Emacs Lisp | =emacs-lisp=  | Plantuml   | =plantuml=   |
-| Eshell | =eshell=  | Processing.js  | =processing= |
-| Fortran| =fortran= | Python | =python= |
-| Gnuplot| =gnuplot= | R  | =R=  |
-| GNU Screen | =screen=  | Ruby   | =ruby=   |
-| Graphviz   | =dot= | Sass   | =sass=   |
-| Haskell| =haskell= | Scheme | =scheme= |
-| Java   | =java=| Sed| =sed=|
-| Javascript | =js=  | shell  | =sh= |
-| LaTeX  | =latex=   | SQL| =sql=|
-| Ledger | =ledger=  | SQLite | =sqlite= |
-| Lilypond   | =lilypond=| Vala   | =vala=   |
-
-Additional documentation for some languages is at
-https://orgmode.org/worg/org-contrib/babel/languages.html.
+Code blocks in dozens of languages are supported.  Language specific
+documentation can be found on [[https://orgmode.org/worg/org-contrib/babel/languages/index.html][Worg]].
 
 #+vindex: org-babel-load-languages
 By default, only Emacs Lisp is enabled for evaluation.  To enable or
-- 
2.25.1

Re: [PATCH] ob-java

[ian martins]

As I was trying to decide who is the author of the ob-java docs, I realized
it's not clear how you're defining authorship due to my confusion about
ob-java.  I can think of three ways to determine authorship:

1. the person that wrote it
2. the people who influenced the code
3. the first person to check in the filename

At first I thought I wrote ob-java by rule 1.  I didn't start from the old
ob-java, and I replaced the entire file.  The patch shows only 10 random
lines of over 400 matched the original ob-java.  If we don't count the
lines that also match ob-template.el, there are only 5.

When you said I didn't write it I thought rule 2 was the next most
reasonable, so I made the authors those that wrote the code that I
referenced.  But after thinking about it more it can't be this.  Adding
languages to babel isn't documented well enough for anyone to do it without
looking at an existing implementation, so going by rule 2 all languages
would be authored by whoever wrote the first one, and they're not.

I'm not sure but I think you'd say I wrote ob-haxe, the ob-haxe tests, the
ob-java tests, and the ob-java docs, but not ob-java.  These match up with
rule 3.  I don't think rule 3 is the one anyone would pick from the list,
but maybe most would subconsciously use it as a heuristic for rule 1, since
rule 1 is hard to establish.  I think the change in authorship is clear for
ob-java because it was replaced in one patch, usually changes are
incremental.  Each file is The Ship of Theseus.  Even if we took the
trouble to determine how much any person wrote, it is difficult to decide
for oneself let alone agree on the amount of change required to establish
new authorship.

But rule 3 doesn't work if a file is rewritten.  If Dostoevsky checks in
the text of "Crime and Punishment" as book.txt, and then Dr. Seuss replaces
the content with "The Cat in the Hat," we'd have to say Dostoevsky wrote
"The Cat in the Hat."

So I think either you didn't notice that I'd replaced the file, or you
considered the lines that matched sufficient for continuity, or you're
thinking about authorship in a way I haven't guessed.  Could you clarify?

On Wed, Oct 28, 2020 at 5:13 AM Bastien  wrote:

> ian martins  writes:
>
> > But I want to follow your conventions. I will put the authors of ob-C
> > and ob-python (Eric Schulte and Dan Davison) as the authors of
> > ob-java and ob-haxe. The implementations are nearly the same. it
> > wouldn't make sense for them to have different authors.
>
> Thanks for doing so!
>
> --
>  Bastien
>

Re: worg changes

[ian martins]

Thanks.  I pushed.  The docs for java are here [1].

It looks like many of the language pages don't pick up their formatting.
Mine did the same at first. Is it fine if I fix them?

The =#+HTML_HEAD:= property breaks them. I suspect that it's existence
blocks the page from picking up the default css. Also It points to an html
id that doesn't exist, so it would have no effect.

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

On Fri, Oct 30, 2020 at 12:40 AM Kyle Meyer  wrote:

> ian martins writes:
>
> > I've written some documentation for ob-java for worg. Should I submit a
> > patch or is it fine to just push? it doesn't modify any existing files.
>
> It's fine to just push.
>

Re: [PATCH] change the ob-java default back to scripting mode

[ian martins]

ok I will do that.

If I make the same change to dozens of tests in the same file, should I
list them as separate bullets, or put the list of function names in
parentheses, or is it better to omit the list if it would be long?

On Wed, Oct 28, 2020 at 9:36 PM Kyle Meyer  wrote:

> ian martins writes:
>
> > Subject: [PATCH] ob-java.el: Change the default back to scripting mode
> >
> > * lisp/ob-java.el: Change the default to scripting mode.  Add name to
> > authors.
>
> The changelog entry should explicitly list the variables/functions that
> are modified.  So in this case
>
> * lisp/ob-java.el (org-babel-default-header-args:java): ...
>
> > A recent commit added functional mode and made it default, but this
> > would break java source blocks for anyone that relied on the old
> > default.  This sets the default back to scripting mode.
>
> Thanks for restoring the behavior.
>
> > I missed a name when I put the authors of ob-C and ob-python as the
> > authors of ob-java.  Added it.
>
> Please move this unrelated change to a separate commit.
>

worg changes

[ian martins]

I've written some documentation for ob-java for worg. Should I submit a
patch or is it fine to just push? it doesn't modify any existing files.
I've seen this question come up on this list before but I haven't seen an
answer. Also I couldn't find the answer on worg [1].

one note: I tweaked the css a bit. I think it makes it easier to read, but
it also doesn't match the other pages.

[1] https://orgmode.org/worg/#orgeb00eb0

[PATCH] change the ob-java default back to scripting mode

[ian martins]

I mentioned this in another thread. Here it is.
From 9ae6cb869ae909396d71000ad7804f49640e51ca Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Tue, 27 Oct 2020 07:00:58 -0400
Subject: [PATCH] ob-java.el: Change the default back to scripting mode

* lisp/ob-java.el: Change the default to scripting mode.  Add name to
authors.

* testing/lisp/test-ob-java.el: Modify the first test to use the
default for `:results' and all others to specify it.  Add name to
authors.

A recent commit added functional mode and made it default, but this
would break java source blocks for anyone that relied on the old
default.  This sets the default back to scripting mode.

I missed a name when I put the authors of ob-C and ob-python as the
authors of ob-java.  Added it.
---
 lisp/ob-java.el  | 11 +--
 testing/lisp/test-ob-java.el | 30 --
 2 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index 05231bee2..c08ede1e7 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -3,6 +3,7 @@
 ;; Copyright (C) 2011-2020 Free Software Foundation, Inc.
 
 ;; Authors: Eric Schulte
+;;  Thierry Banel
 ;;  Dan Davison
 ;; Maintainer: Ian Martins 
 ;; Keywords: literate programming, reproducible research
@@ -35,8 +36,14 @@
 
 (defvar org-babel-temporary-directory) ; from ob-core
 
-(defvar org-babel-default-header-args:java '()
-  "Default header args for java source blocks.")
+(defvar org-babel-default-header-args:java '((:results . "output"))
+  "Default header args for java source blocks.
+The docs say functional mode should be the default [1], but
+ob-java didn't support functional mode until recently, so we keep
+scripting mode as the default for now to maintain existing
+behavior.
+
+[1] https://orgmode.org/manual/Results-of-Evaluation.html;)
 
 (defconst org-babel-header-args:java '((imports . :any))
   "Java-specific header arguments.")
diff --git a/testing/lisp/test-ob-java.el b/testing/lisp/test-ob-java.el
index b8f34253f..b055f5a02 100644
--- a/testing/lisp/test-ob-java.el
+++ b/testing/lisp/test-ob-java.el
@@ -2,6 +2,7 @@
 
 ;; Copyright (c) 2020 Free Software Foundation, Inc.
 ;; Authors: Eric Schulte
+;;  Thierry Banel
 ;;          Dan Davison
 ;; Maintainer: Ian Martins 
 
@@ -37,9 +38,10 @@
 ; simple tests
 
 (ert-deftest ob-java/simple ()
-  "Hello world program that writes output."
+  "Hello world program that writes output. Also tests that
+ob-java defaults to scripting mode."
   (org-test-with-temp-text
-  "#+begin_src java :results output silent
+  "#+begin_src java :results silent
 System.out.print(42);
 #+end_src"
(should (string= "42" (org-babel-execute-src-block)
@@ -63,7 +65,7 @@ System.out.print(\"\\\"42\\\"\");
 (ert-deftest ob-java/simple-return-int ()
   "Hello world program that returns an int value."
   (org-test-with-temp-text
-  "#+begin_src java :results silent
+  "#+begin_src java :results value silent
 return 42;
 #+end_src"
(should (eq 42 (org-babel-execute-src-block)
@@ -71,7 +73,7 @@ return 42;
 (ert-deftest ob-java/simple-return-float ()
   "Hello world program that returns a float value."
   (org-test-with-temp-text
-  "#+begin_src java :results silent
+  "#+begin_src java :results value silent
 return 42.0;
 #+end_src"
(should (equal 42.0 (org-babel-execute-src-block)
@@ -79,7 +81,7 @@ return 42.0;
 (ert-deftest ob-java/simple-return-string ()
   "Hello world program that returns a string value."
   (org-test-with-temp-text
-  "#+begin_src java :results silent
+  "#+begin_src java :results value silent
 return \"forty two\";
 #+end_src"
 (should (string= "forty two" (org-babel-execute-src-block)
@@ -291,7 +293,7 @@ System.out.print(String.format(\"%s, len=%d\", a, a.length()));
 (ert-deftest ob-java/return-vector-using-list ()
   "Return a vector using a list."
   (org-test-with-temp-text
-  "#+begin_src java :results vector silent
+  "#+begin_src java :results value vector silent
 import java.util.List;
 import java.util.Arrays;
 List> a = Arrays.asList(Arrays.asList(4),
@@ -304,7 +306,7 @@ return a;
 (ert-deftest ob-java/return-vector-using-array ()
   "Return a vector using an array."
   (org-test-with-temp-text
-  "#+begin_src java :results vector silent
+  "#+begin_src java :results value vector silent
 Integer[][] a = {{4}, {2}};
 return a;
 #+end_src"
@@ -314,7 +316,7 @@ return a;
 (ert-deftest ob-java/read-return-list ()
   "Read and return a list."
   (org-test-with-temp-text
-  "#+begin_src java :var a=java_list :results silent
+  "#+begin_src java :var a=java_list :results value silent
 import java.util.L

default :results

[ian martins]

The doc says functional mode (=:results value=) is the default for most
Babel libraries [1].  I haven't looked at many, but it is the default for
ob-python and ob-shell. Scripting mode (=:results output=) is the default
for ob-C, and the old ob-java (neither of these provided a functional mode).

When I added functional mode to ob-java, I made it the default since that
seemed correct.  But that change breaks anyone that relied on the old
default (the workaround is to add a =:results output= header).  I will
change the default in the short term to unbreak the experience, but what,
if anything, should be done long term?

And is this inconsistent behavior across languages something that should be
fixed? or is it intentional or at least not worth doing anything about?

[1]
https://orgmode.org/manual/Results-of-Evaluation.html#Results-of-Evaluation

Re: [PATCH] ob-java

[ian martins]

I made the changes, updated the commit message for the large patch, and
pushed.

On Sat, Oct 24, 2020 at 10:40 PM Kyle Meyer  wrote:

> ian martins writes:
>
> > After making the changes, should I submit updated patches or is it fine
> to
> > push?
>
> Push away.  Thanks again.
>

Re: [PATCH] ob-java

[ian martins]

Thanks for the feedback. In general, the changes are all intended to be
backwards compatible. Thanks for pointing out changes that weren't.

After making the changes, should I submit updated patches or is it fine to
push?

On Sat, Oct 24, 2020 at 1:05 PM Kyle Meyer  wrote:

> Hi ian,
>
> ian martins writes:
>
> >> * Changes
> >>
> >> - support for functional mode (~:results value~)
> >> - accept variables
> >> - don't require package, class, and main definitions
> >> - write source and result tempfiles to ~org-babel-temporary-directory~,
> >> but respects the ~:dir~ header
> >> - work with tramp
>
> Thanks for all the work you've put into this.  As someone that knows
> nothing about Java and hasn't touched ob-java, that sounds good :)
>
> I see this got a "feel free to install" elsewhere in this thread, so
> here are a few scattered and superficial remarks.
>
> > Subject: [PATCH] ob-java.el: Add support for variables, return values,
> tramp
> >
> > * lisp/ob-java.el: Add support for variables and return values.  Write
> > tempfiles to the org-babel-temporary-directory.  Make package, class,
> > and main method definitions optional.
> >
> > * testing/lisp/test-ob-java.el: Add tests.
>
> I think the changelog entry should technically have
> per-function/variable entries.
>
> More importantly from my perspective, it would be great for the message
> to explain what the current state is, why it is problematic, and what
> the patch's solution is.  For this patch, that'd probably be much too
> large, which is a good indication that it'd be better presented as a
> split up series.  But, at this point, that's not something I think you
> should do for this patch, especially given there doesn't seem to be a
> java/ob-java user with the bandwidth to provide a detailed review.
>
> > -(defcustom org-babel-java-command "java"
> > -  "Name of the java command.
> > -May be either a command in the path, like java
> > -or an absolute path name, like /usr/local/bin/java
> > -parameters may be used, like java -verbose"
> > +(defvar org-babel-default-header-args:java '()
> > +  "Default header args for java source blocks.")
> > +
> > +(defconst org-babel-header-args:java '((imports . :any))
> > +  "Java-specific header arguments.")
> > +
> > +(defvar org-babel-java-compiler-command "javac"
> > +  "Name of the command to execute the java compiler.")
> > +
> > +(defvar org-babel-java-runtime-command "java"
> > +  "Name of the command to run the java runtime.")
>
> Rather than dropping org-babel-java-command and org-babel-java-compiler
> entirely, can you make this change in a way that doesn't break for users
> that have already customized org-babel-java-command?
>
> Also, shouldn't org-babel-java-compiler-command and
> org-babel-java-runtime-command be user options rather than defvars?
>
> In general, are the changes here expected to be backwards compatible for
> current ob-java users?
>
> > +(defcustom org-babel-java-hline-to "null"
> > +  "Replace hlines in incoming tables with this when translating to
> java."
> >:group 'org-babel
> > -  :version "24.3"
> > +  :version "25.2"
> > +  :package-version '(Org . "9.3")
> >:type 'string)
> >
> > -(defcustom org-babel-java-compiler "javac"
> > -  "Name of the java compiler.
> > -May be either a command in the path, like javac
> > -or an absolute path name, like /usr/local/bin/javac
> > -parameters may be used, like javac -verbose"
> > +(defcustom org-babel-java-null-to 'hline
> > +  "Replace `null' in java tables with this before returning."
> >:group 'org-babel
> > -  :version "24.3"
> > -  :type 'string)
> > +  :version "25.2"
> > +  :package-version '(Org . "9.3")
> > +  :type 'symbol)
>
> For both these options, s/9.3/9.5/.  And please drop :version, letting
> it be handled by customize-package-emacs-version-alist.
>
> >  (defun org-babel-execute:java (body params)
> > -  (let* ((classname (or (cdr (assq :classname params))
> > - (error
> > -  "Can't compile a java block without a
> classname")))
> > -  (packagename (file-name-directory classname))
> > -  (src-file (concat classname ".java"))
> > +  "Execute a java source block with BODY code and PARAMS params."
> > +  (let* (;; if true, run from

Re: [PATCH] ob-java

[ian martins]

This happened because the new ob-java wasn't based on the old ob-java. I
wrote ob-haxe based on ob-C and ob-python and then derived ob-java from
ob-haxe.  I went back and forth about who should be the author of ob-haxe.
I considered listing the authors of ob-C and ob-python, but I thought it
wouldn't make sense since they may not have heard of haxe, and they may not
like my code or want their names on it. I didn't really think about the
author of the new ob-java, since it came directly from ob-haxe.

But I want to follow your conventions. I will put the authors of ob-C and
ob-python (Eric Schulte and Dan Davison) as the authors of ob-java and
ob-haxe. The implementations are nearly the same. it wouldn't make sense
for them to have different authors.

On Sat, Oct 24, 2020 at 7:58 AM Bastien  wrote:

> Hi Ian,
>
> feel free to install the patch when you think it's ready.
>
> One minor nitpick:
>
> -;; Author: Eric Schulte
> -;; Maintainer: Ian Martins 
> +;; Author: Ian Martins 
>
> I suggest you leave Eric Schulte as the author while adding yourself
> as the maintainer, even if the "change" is a big rewrite.
>
> Thanks,
>
> --
>  Bastien
>

Re: [PATCH] ob-java

[ian martins]

Actually I realized if I keep the commits separate and generate a patch set
instead of squashing then I can preserve authorship.

These patches, which follow patch 0001, fix the spacing and allow
non-public classes.

Thanks again for testing, debugging, and reporting.

On Wed, Oct 21, 2020 at 9:54 AM John Herrlin  wrote:

>
> ian martins  writes:
>
> >>
> >> What do you think about having a configurable list where the user can
> >> add =org-babel-java--import-maybe=? In my current use case I could then
> >> add RxJava imports to that list and the imports could be removed from
> >> the source code block.
> >
> >
> > I think this can already be done. imports can be added to the headers,
> and
> > babel allows file-wide headers, so you could add a =#+HEADER: :import
> > rx.Observable= line to the file and all source blocks would get it.  it's
> > slightly different in that =org-babel-java--import-maybe= skips imports
> > that it thinks aren't needed. also if there are any non-java source
> blocks
> > in the same file, these imports could be added to them which would be
> bad,
> > so when mixing multiple languages in the same file this wouldn't be an
> > option.
>
> Thanks for pointing that out! It work just fine!
>
> >
> > NIT
> >> Some spacing when writing =public static...=
> >>
> >
> > Thanks for fixing the spacing. I don't think I can give you credit for
> the
> > patch, though, without leaving it out until ob-java is accepted.
>
> I dont need any credits, the important part is the result!
>
> I have made a couple of more runs and I cant find anything that doesnt
> work!
>
> >
> > On Wed, Oct 21, 2020 at 1:59 AM John Herrlin  wrote:
> >
> >>
> >> I did and it looks really good. The difference in this example:
> >>
> >> #+BEGIN_SRC java
> >>   import rx.Observable;
> >>
> >>   Observable.range(5, 3)
> >>   .subscribe((Integer i) ->   { System.out.println("Got: " +
> i); },
> >>  (Throwable t) -> { t.printStackTrace();},
> >>  () ->{ System.out.println("Ending
> >> stream"); });
> >> #+END_SRC
> >>
> >> from the ones I posted yesterday is tremendous!
> >>
> >> I am not very experienced with Emacs lisp but I think it's pretty easy
> >> to understand how things works and follow the code. The comments are
> >> also of good help. I really appreciate the work you have done!
> >>
> >>
> >> What do you think about having a configurable list where the user can
> >> add =org-babel-java--import-maybe=? In my current use case I could then
> >> add RxJava imports to that list and the imports could be removed from
> >> the source code block.
> >>
> >>
> >> NIT
> >>
> >> Some spacing when writing =public static...=
> >>
> >>#+BEGIN_SRC diff
> >>  diff --git a/lisp/ob-java.el b/lisp/ob-java.el
> >>  index 94c3f69cf..4f3904871 100644
> >>  --- a/lisp/ob-java.el
> >>  +++ b/lisp/ob-java.el
> >>  @@ -220,7 +220,7 @@ RESULT-FILE is the temp file to write the
> result."
> >> (org-babel-java--move-past org-babel-java--class-re)
> >> (insert "\npublic static void main(String[] args) {
> >>   System.out.print(\"success\");
> >>  -}\n\n"))
> >>  +}\n\n"))
> >>
> >>   ;; special handling to return value
> >>   (when (eq result-type 'value)
> >>#+END_SRC
> >>
> >>
> >>
> >> ian martins  writes:
> >>
> >> > Thanks for testing, and thanks for pointing that out. I will fix it so
> >> that
> >> > `public` is optional.
> >> >
> >> > btw, in your example you didn't have to specify `:classname` since you
> >> > defined the class name in the source block.
> >> >
> >> > btw2, did you notice that you can C-c C-c on source blocks that don't
> >> have
> >> > main methods and it'll compile without error?
> >> >
> >> > On Tue, Oct 20, 2020 at 3:17 PM John Herrlin 
> wrote:
> >> >
> >> >>
> >> >> Hey,
> >> >>
> >> >> Did some debugging and found out that my class didn't contained
> =public=
> >> >> and the patch requires it to be.

Re: [PATCH] ob-java

[ian martins]

>
> What do you think about having a configurable list where the user can
> add =org-babel-java--import-maybe=? In my current use case I could then
> add RxJava imports to that list and the imports could be removed from
> the source code block.


I think this can already be done. imports can be added to the headers, and
babel allows file-wide headers, so you could add a =#+HEADER: :import
rx.Observable= line to the file and all source blocks would get it.  it's
slightly different in that =org-babel-java--import-maybe= skips imports
that it thinks aren't needed. also if there are any non-java source blocks
in the same file, these imports could be added to them which would be bad,
so when mixing multiple languages in the same file this wouldn't be an
option.

NIT
> Some spacing when writing =public static...=
>

Thanks for fixing the spacing. I don't think I can give you credit for the
patch, though, without leaving it out until ob-java is accepted.

On Wed, Oct 21, 2020 at 1:59 AM John Herrlin  wrote:

>
> I did and it looks really good. The difference in this example:
>
> #+BEGIN_SRC java
>   import rx.Observable;
>
>   Observable.range(5, 3)
>   .subscribe((Integer i) ->   { System.out.println("Got: " + i); },
>  (Throwable t) -> { t.printStackTrace();},
>  () ->{ System.out.println("Ending
> stream"); });
> #+END_SRC
>
> from the ones I posted yesterday is tremendous!
>
> I am not very experienced with Emacs lisp but I think it's pretty easy
> to understand how things works and follow the code. The comments are
> also of good help. I really appreciate the work you have done!
>
>
> What do you think about having a configurable list where the user can
> add =org-babel-java--import-maybe=? In my current use case I could then
> add RxJava imports to that list and the imports could be removed from
> the source code block.
>
>
> NIT
>
> Some spacing when writing =public static...=
>
>#+BEGIN_SRC diff
>  diff --git a/lisp/ob-java.el b/lisp/ob-java.el
>  index 94c3f69cf..4f3904871 100644
>  --- a/lisp/ob-java.el
>  +++ b/lisp/ob-java.el
>  @@ -220,7 +220,7 @@ RESULT-FILE is the temp file to write the result."
> (org-babel-java--move-past org-babel-java--class-re)
> (insert "\npublic static void main(String[] args) {
>   System.out.print(\"success\");
>  -}\n\n"))
>  +}\n\n"))
>
>   ;; special handling to return value
>   (when (eq result-type 'value)
>#+END_SRC
>
>
>
> ian martins  writes:
>
> > Thanks for testing, and thanks for pointing that out. I will fix it so
> that
> > `public` is optional.
> >
> > btw, in your example you didn't have to specify `:classname` since you
> > defined the class name in the source block.
> >
> > btw2, did you notice that you can C-c C-c on source blocks that don't
> have
> > main methods and it'll compile without error?
> >
> > On Tue, Oct 20, 2020 at 3:17 PM John Herrlin  wrote:
> >
> >>
> >> Hey,
> >>
> >> Did some debugging and found out that my class didn't contained =public=
> >> and the patch requires it to be.
> >>
> >> This works fine:
> >>
> >>#+HEADER: :classname Main
> >>#+HEADER: :dir src
> >>#+HEADER: :cmdline -classpath ./rxjava-1.3.8.jar:.
> >>#+HEADER: :cmpflag -classpath ./rxjava-1.3.8.jar
> >>#+BEGIN_SRC java :results output code
> >>  import rx.Observable;
> >>  public class Main {
> >>  public static void main(String[] args) {
> >>  Observable.range(5, 5)
> >>  .subscribe(System.out::println);
> >>  }
> >>  }
> >>#+END_SRC
> >>
> >>
> >>
> >>
> >> ian martins  writes:
> >>
> >> > I noticed that the tests didn't run with "make test." This updates the
> >> > patch so that they can. I didn't add java to the list of default
> >> languages
> >> > because the java tests are slow.
> >> >
> >> > On Mon, Oct 5, 2020 at 9:23 AM ian martins  wrote:
> >> >
> >> >> I wrote those examples in an org file so I could test as I wrote
> them,
> >> and
> >> >> then exported it to make it more readable, but the export resulted in
> >> >> source block headers being lost.  Here is the same without export:
> >> >> 
> >> &

Re: [PATCH] ob-java

[ian martins]

Thanks for testing, and thanks for pointing that out. I will fix it so that
`public` is optional.

btw, in your example you didn't have to specify `:classname` since you
defined the class name in the source block.

btw2, did you notice that you can C-c C-c on source blocks that don't have
main methods and it'll compile without error?

On Tue, Oct 20, 2020 at 3:17 PM John Herrlin  wrote:

>
> Hey,
>
> Did some debugging and found out that my class didn't contained =public=
> and the patch requires it to be.
>
> This works fine:
>
>#+HEADER: :classname Main
>#+HEADER: :dir src
>#+HEADER: :cmdline -classpath ./rxjava-1.3.8.jar:.
>#+HEADER: :cmpflag -classpath ./rxjava-1.3.8.jar
>#+BEGIN_SRC java :results output code
>  import rx.Observable;
>  public class Main {
>  public static void main(String[] args) {
>  Observable.range(5, 5)
>  .subscribe(System.out::println);
>  }
>  }
>#+END_SRC
>
>
>
>
> ian martins  writes:
>
> > I noticed that the tests didn't run with "make test." This updates the
> > patch so that they can. I didn't add java to the list of default
> languages
> > because the java tests are slow.
> >
> > On Mon, Oct 5, 2020 at 9:23 AM ian martins  wrote:
> >
> >> I wrote those examples in an org file so I could test as I wrote them,
> and
> >> then exported it to make it more readable, but the export resulted in
> >> source block headers being lost.  Here is the same without export:
> >> 
> >> * Changes
> >>
> >> - support for functional mode (~:results value~)
> >> - accept variables
> >> - don't require package, class, and main definitions
> >> - write source and result tempfiles to ~org-babel-temporary-directory~,
> >> but respects the ~:dir~ header
> >> - work with tramp
> >>
> >> * Examples
> >> ** Example 1
> >> This outputs "hello."  If class and main definitions aren't given the
> >> code block will be wrapped in generic ones.
> >>
> >> #+begin_src java :results output silent
> >>   System.out.print("hello");
> >> #+end_src
> >>
> >> This is exactly equivalent:
> >>
> >> #+begin_src java :results output silent
> >>   public class Main {
> >>   public static void main(String[] args) {
> >>   System.out.print("hello");
> >>   }
> >>   }
> >> #+end_src
> >>
> >> ** Example 2
> >> This also outputs "hello."
> >>
> >> #+begin_src java :results value silent
> >>   return "hello";
> >> #+end_src
> >>
> >> ** Example 3
> >> This generates the class "Example" in the package "org.orgmode" in the
> >> current directory.
> >>
> >> #+begin_src java :results output silent :classname org.orgmode.Example
> >> :dir .
> >>   System.out.print("hello, org-mode");
> >> #+end_src
> >>
> >> ** Example 4
> >> The "Hey" class defines a static method but no main. C-c C-c on the
> >> "Hey" source block will write "./org/orgmode/Hey.java" and compile it.
> >>
> >> The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
> >> block will write "./org/orgmode/Main.java" and compile and run it.
> >>
> >> #+begin_src java :results output silent :dir .
> >>   package org.orgmode;
> >>
> >>   public class Hey {
> >>   public static String say() {
> >>   return "hey";
> >>   }
> >>   }
> >> #+end_src
> >>
> >> #+begin_src java :results output silent :dir .
> >>   package org.orgmode;
> >>
> >>   public class Main {
> >>   public static void main(String[] args) {
> >>   System.out.print(Hey.say());
> >>   }
> >>   }
> >> #+end_src
> >>
> >> Instead of C-c C-c, we could have added tangle headers and written the
> >> source files out by tangling.
> >>
> >> ** Example 5
> >> This prints the variable from the header
> >>
> >> #+begin_src java :var msg="hello, org-mode" :results output silent
> >>   System.out.print(msg);
> >> #+end_src
> >>
> >> ** Example 6
> >> This prints "hello, org-mode." The table is pro

Re: [PATCH] ob-java

[ian martins]

I noticed that the tests didn't run with "make test." This updates the
patch so that they can. I didn't add java to the list of default languages
because the java tests are slow.

On Mon, Oct 5, 2020 at 9:23 AM ian martins  wrote:

> I wrote those examples in an org file so I could test as I wrote them, and
> then exported it to make it more readable, but the export resulted in
> source block headers being lost.  Here is the same without export:
> 
> * Changes
>
> - support for functional mode (~:results value~)
> - accept variables
> - don't require package, class, and main definitions
> - write source and result tempfiles to ~org-babel-temporary-directory~,
> but respects the ~:dir~ header
> - work with tramp
>
> * Examples
> ** Example 1
> This outputs "hello."  If class and main definitions aren't given the
> code block will be wrapped in generic ones.
>
> #+begin_src java :results output silent
>   System.out.print("hello");
> #+end_src
>
> This is exactly equivalent:
>
> #+begin_src java :results output silent
>   public class Main {
>   public static void main(String[] args) {
>   System.out.print("hello");
>   }
>   }
> #+end_src
>
> ** Example 2
> This also outputs "hello."
>
> #+begin_src java :results value silent
>   return "hello";
> #+end_src
>
> ** Example 3
> This generates the class "Example" in the package "org.orgmode" in the
> current directory.
>
> #+begin_src java :results output silent :classname org.orgmode.Example
> :dir .
>   System.out.print("hello, org-mode");
> #+end_src
>
> ** Example 4
> The "Hey" class defines a static method but no main. C-c C-c on the
> "Hey" source block will write "./org/orgmode/Hey.java" and compile it.
>
> The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
> block will write "./org/orgmode/Main.java" and compile and run it.
>
> #+begin_src java :results output silent :dir .
>   package org.orgmode;
>
>   public class Hey {
>   public static String say() {
>   return "hey";
>   }
>   }
> #+end_src
>
> #+begin_src java :results output silent :dir .
>   package org.orgmode;
>
>   public class Main {
>   public static void main(String[] args) {
>   System.out.print(Hey.say());
>   }
>   }
> #+end_src
>
> Instead of C-c C-c, we could have added tangle headers and written the
> source files out by tangling.
>
> ** Example 5
> This prints the variable from the header
>
> #+begin_src java :var msg="hello, org-mode" :results output silent
>   System.out.print(msg);
> #+end_src
>
> ** Example 6
> This prints "hello, org-mode." The table is provided to the method as a
> list of lists.
>
> #+name: table
> | message | hello, org-mode  |
>
> #+begin_src java :var tbl=table :results output silent
>   System.out.print(tbl.get(0).get(1));
> #+end_src
>
> ** Example 7
> This example returns a list.
>
> Note that you're allowed to specify imports without defining the class
> or main methods.
>
> #+begin_src java :results value :exports both
>   import java.util.Arrays;
>
>   return Arrays.asList("message", "hello, org-mode");
> #+end_src
>
> #+RESULTS:
> | message | hello, org-mode |
>
> On Mon, Oct 5, 2020 at 8:35 AM ian martins  wrote:
>
>> 1 Changes
>> =
>>
>>   - support for functional mode (`:results value')
>>   - accept variables
>>   - don't require package, class, and main definitions
>>   - write source and result tempfiles to
>> `org-babel-temporary-directory', but respects the `:dir' header
>>   - work with tramp
>>
>>
>> 2 Examples
>> ==
>> Some examples follow.  See the tests for more examples.  I'll write
>> proper docs after review.
>>
>> 2.1 Example 1
>> ~
>>
>>   This outputs "hello."  If class and main definitions aren't given the
>>   code block will be wrapped in generic ones.
>>
>>   ,
>>   | System.out.print("hello");
>>   `
>>
>>   This is exactly equivalent:
>>
>>   ,
>>   | public class Main {
>>   | public static void main(String[] args) {
>>   | System.out.print("hello");
>>   | }
>>   | }
>>   `
>>
>>
>> 2.2 Example 2
>> ~
>>
>>   This also outputs "hello."
>>
>>

Re: [PATCH] ob-java

[ian martins]

I wrote those examples in an org file so I could test as I wrote them, and
then exported it to make it more readable, but the export resulted in
source block headers being lost.  Here is the same without export:

* Changes

- support for functional mode (~:results value~)
- accept variables
- don't require package, class, and main definitions
- write source and result tempfiles to ~org-babel-temporary-directory~, but
respects the ~:dir~ header
- work with tramp

* Examples
** Example 1
This outputs "hello."  If class and main definitions aren't given the
code block will be wrapped in generic ones.

#+begin_src java :results output silent
  System.out.print("hello");
#+end_src

This is exactly equivalent:

#+begin_src java :results output silent
  public class Main {
  public static void main(String[] args) {
  System.out.print("hello");
  }
  }
#+end_src

** Example 2
This also outputs "hello."

#+begin_src java :results value silent
  return "hello";
#+end_src

** Example 3
This generates the class "Example" in the package "org.orgmode" in the
current directory.

#+begin_src java :results output silent :classname org.orgmode.Example :dir
.
  System.out.print("hello, org-mode");
#+end_src

** Example 4
The "Hey" class defines a static method but no main. C-c C-c on the
"Hey" source block will write "./org/orgmode/Hey.java" and compile it.

The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
block will write "./org/orgmode/Main.java" and compile and run it.

#+begin_src java :results output silent :dir .
  package org.orgmode;

  public class Hey {
  public static String say() {
  return "hey";
  }
  }
#+end_src

#+begin_src java :results output silent :dir .
  package org.orgmode;

  public class Main {
  public static void main(String[] args) {
  System.out.print(Hey.say());
  }
  }
#+end_src

Instead of C-c C-c, we could have added tangle headers and written the
source files out by tangling.

** Example 5
This prints the variable from the header

#+begin_src java :var msg="hello, org-mode" :results output silent
  System.out.print(msg);
#+end_src

** Example 6
This prints "hello, org-mode." The table is provided to the method as a
list of lists.

#+name: table
| message | hello, org-mode  |

#+begin_src java :var tbl=table :results output silent
  System.out.print(tbl.get(0).get(1));
#+end_src

** Example 7
This example returns a list.

Note that you're allowed to specify imports without defining the class
or main methods.

#+begin_src java :results value :exports both
  import java.util.Arrays;

  return Arrays.asList("message", "hello, org-mode");
#+end_src

#+RESULTS:
| message | hello, org-mode |

On Mon, Oct 5, 2020 at 8:35 AM ian martins  wrote:

> 1 Changes
> =
>
>   - support for functional mode (`:results value')
>   - accept variables
>   - don't require package, class, and main definitions
>   - write source and result tempfiles to
> `org-babel-temporary-directory', but respects the `:dir' header
>   - work with tramp
>
>
> 2 Examples
> ==
> Some examples follow.  See the tests for more examples.  I'll write proper
> docs after review.
>
> 2.1 Example 1
> ~
>
>   This outputs "hello."  If class and main definitions aren't given the
>   code block will be wrapped in generic ones.
>
>   ,
>   | System.out.print("hello");
>   `
>
>   This is exactly equivalent:
>
>   ,
>   | public class Main {
>   | public static void main(String[] args) {
>   | System.out.print("hello");
>   | }
>   | }
>   `
>
>
> 2.2 Example 2
> ~
>
>   This also outputs "hello."
>
>   ,
>   | return "hello";
>   `
>
>
> 2.3 Example 3
> ~
>
>   This generates the class "Example" in the package "org.orgmode" in the
>   current directory.
>
>   ,
>   | System.out.print("hello, org-mode");
>   `
>
>
> 2.4 Example 4
> ~
>
>   The "Hey" class defines a static method but no main. C-c C-c on the
>   "Hey" source block will write "./org/orgmode/Hey.java" and compile it.
>
>   The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
>   block will write "./org/orgmode/Main.java" and compile and run it.
>
>   ,
>   | package org.orgmode;
>   |
>   | public class Hey {
>   | public static String say() {
>   | return "hey";
>   | }
>   

[PATCH] ob-java

[ian martins]

1 Changes
=

  - support for functional mode (`:results value')
  - accept variables
  - don't require package, class, and main definitions
  - write source and result tempfiles to
`org-babel-temporary-directory', but respects the `:dir' header
  - work with tramp


2 Examples
==
Some examples follow.  See the tests for more examples.  I'll write proper
docs after review.

2.1 Example 1
~

  This outputs "hello."  If class and main definitions aren't given the
  code block will be wrapped in generic ones.

  ,
  | System.out.print("hello");
  `

  This is exactly equivalent:

  ,
  | public class Main {
  | public static void main(String[] args) {
  | System.out.print("hello");
  | }
  | }
  `


2.2 Example 2
~

  This also outputs "hello."

  ,
  | return "hello";
  `


2.3 Example 3
~

  This generates the class "Example" in the package "org.orgmode" in the
  current directory.

  ,
  | System.out.print("hello, org-mode");
  `


2.4 Example 4
~

  The "Hey" class defines a static method but no main. C-c C-c on the
  "Hey" source block will write "./org/orgmode/Hey.java" and compile it.

  The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
  block will write "./org/orgmode/Main.java" and compile and run it.

  ,
  | package org.orgmode;
  |
  | public class Hey {
  | public static String say() {
  | return "hey";
  | }
  | }
  `

  ,
  | package org.orgmode;
  |
  | public class Main {
  | public static void main(String[] args) {
  | System.out.print(Hey.say());
  | }
  | }
  `

  Instead of C-c C-c, we could have added tangle headers and written the
  source files out by tangling.


2.5 Example 5
~

  This prints the variable from the header

  ,
  | System.out.print(msg);
  `


2.6 Example 6
~

  This prints "hello, org-mode." The table is provided to the method as
  a list of lists.

   message  hello, org-mode

  ,
  | System.out.print(tbl.get(0).get(1));
  `


2.7 Example 7
~

  This example returns a list.

  Note that you're allowed to specify imports without defining the class
  or main methods.

  ,
  | import java.util.Arrays;
  |
  | return Arrays.asList("message", "hello, org-mode");
  `

   message  hello, org-mode
From e525a1328fee6f764c40a2158376d78e406391ae Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Mon, 5 Oct 2020 08:07:25 -0400
Subject: [PATCH] ob-java.el: Add support for variables, return values, tramp

* lisp/ob-java.el: Add support for variables and return values.  Write
tempfiles to the org-babel-temporary-directory.  Make package, class,
and main method definitions optional.

* testing/lisp/test-ob-java.el: Add tests.
---
 lisp/ob-java.el  | 425 +++---
 testing/lisp/test-ob-java.el | 574 +++
 2 files changed, 958 insertions(+), 41 deletions(-)
 create mode 100644 testing/lisp/test-ob-java.el

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index fee695bb9..94c3f69cf 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -1,9 +1,8 @@
-;;; ob-java.el --- Babel Functions for Java  -*- lexical-binding: t; -*-
+;;; ob-java.el --- org-babel functions for java evaluation -*- lexical-binding: t -*-
 
 ;; Copyright (C) 2011-2020 Free Software Foundation, Inc.
 
-;; Author: Eric Schulte
-;; Maintainer: Ian Martins 
+;; Author: Ian Martins 
 ;; Keywords: literate programming, reproducible research
 ;; Homepage: https://orgmode.org
 
@@ -24,61 +23,405 @@
 
 ;;; Commentary:
 
-;; Currently this only supports the external compilation and execution
-;; of java code blocks (i.e., no session support).
+;; Org-Babel support for evaluating java source code.
 
 ;;; Code:
 (require 'ob)
 
+(defvar org-babel-temporary-directory) ; from ob-core
+
 (defvar org-babel-tangle-lang-exts)
 (add-to-list 'org-babel-tangle-lang-exts '("java" . "java"))
 
-(defcustom org-babel-java-command "java"
-  "Name of the java command.
-May be either a command in the path, like java
-or an absolute path name, like /usr/local/bin/java
-parameters may be used, like java -verbose"
+(defvar org-babel-default-header-args:java '()
+  "Default header args for java source blocks.")
+
+(defconst org-babel-header-args:java '((imports . :any))
+  "Java-specific header arguments.")
+
+(defvar org-babel-java-compiler-command "javac"
+  "Name of the command to execute the java compiler.")
+
+(defvar org-babel-java-runtime-command "java"
+  "Name of the command to run the java runtime.")
+
+(defcustom org-babel-java-hline-to "

Re: org-babel support for haxe

[ian martins]

I wrote the ob-core patch I mentioned before but white writing the commit
message I realized there's probably no need to modify ob-core at all. I was
doing it in order to allow haxe and java to create subdirectories in the
babel temp directory since both languages require class names to match file
names and directory structures to match the class' package (which is like
namespace in C). But for executing babel code blocks from the temp
directory all that is needed is the output; the source file doesn't matter.
I'll try updating the haxe and java patches to build and run directly from
the babel temp directory.

On Thu, Sep 24, 2020 at 5:17 PM ian martins  wrote:

> with ob-java I assumed I shouldn't change ob-core, so I advised/overrode
> ob-core instead of changing it. But it would be much better to change
> ob-core. I'll submit those changes as a separate patch that modifies
> ob-core.
>
> On Sun, Sep 13, 2020 at 4:04 PM Kyle Meyer  wrote:
>
>> ian martins writes:
>>
>> > ob-haxe and ob-java both involve a few changes to ob-core to allow temp
>> > directories instead of just temp files. Should I submit that as a
>> separate
>> > patch?
>>
>> It looks like that change is included with your ob-java patch [0], which
>> will be considered after 9.4 is released [1], so I think it's fine as
>> is.  (In my opinion, splitting up that patch would have been nice, but I
>> don't think it's worth a reroll, at least until some initial comments
>> come in.)
>>
>> [0]
>> https://orgmode.org/list/CAC=rjb7ahmnrq9nc4ao07qk3qzf4lvatmu_r1fwqr+97npn...@mail.gmail.com
>> [1] https://orgmode.org/list/87sgbwgvx6@gnu.org
>>
>

Re: ob-java compile only

[ian martins]

Thanks for explaining. That makes sense.

I'm hesitant to add the compile-only header for a couple reasons. Generally
C-c C-c on a source block means "run this" but with compile-only it'll mean
"run this but don't run it." It's semantically inconsistent. Also I want to
bring more feature parity to ob-java, so that there's more consistency
across babel. I'm reluctant to add headers not found elsewhere.

Consider some alternatives:
1. one option is to add a dummy main to every class. it could do nothing or
run unit tests. it's not a bad place to kick off unit tests, but I don't
think you should have to.
2. you could use org-babel-tangle to write out the source files, and
compile from an emacs compile buffer. this might be more convenient than
compiling from babel since recompiles are a single keystroke.
3. a future version of ob-java will know if a class has a "public static
void main." at that point it'll be easy to automatically skip execution of
the class if it doesn't define a main, without the need for a new header.

On Mon, Sep 28, 2020 at 4:11 AM John Herrlin  wrote:

>
> Hey Ian,
>
> Thank you for the quick feedback!
>
> That workflow seems to work perfectly if it's Java all the way. Then it
> compiles all the related files. I am mostly working with the classes
> from Clojure.
>
> Here is an example:
>
>#+HEADER: :classname se/my_test_package/Hey
>#+HEADER: :compile-only t
>#+HEADER: :results none
>#+HEADER: :dir src
>#+BEGIN_SRC java
>  package se.my_test_package;
>
>  public class Hey {
>  public static String hey(String name) {
>  return "Hey " + name;
>  }
>  }
>#+END_SRC
>
>#+BEGIN_SRC clojure :results output code
>  (import [se.my_test_package Hey])
>
>  (Hey/hey "John")
>#+END_SRC
>
>
> Best regards
>
>
>
> ian martins  writes:
>
> > Hi John,
> >
> > Thanks for the suggestion and patch. Is the reason for this so that you
> can
> > have classes without needing dummy "main" methods?
> >
> > Did you consider using org-babel-tangle to generate the source files?
> This
> > works for me:
> >
> > Steps:
> > 1. put javatangle.org (below) on your local.
> > 2. create "pkg" directory where javatangle.org is
> > 3. run org-babel-tangle on javatangle.org (this writes two source files
> to
> > the pkg dir)
> > 4. run C-c C-c on the top source block (this compiles both source files
> and
> > runs main)
> >
> > - javatangle.org -
> >
> > #+begin_src java :results output :classname pkg/Main :tangle
> pkg/Main.java
> >   package pkg;
> >
> >   public class Main {
> >   public static void main(String[] args) {
> >   System.out.println(Hey.hey());
> >   }
> >   }
> > #+end_src
> >
> > #+begin_src java :results output :classname pkg/Hey :tangle pkg/Hey.java
> >   package pkg;
> >
> >   public class Hey {
> >   public static String hey() {
> >   return "hey";
> >   }
> >   }
> > #+end_src
> >
> >
> >
> > On Sun, Sep 27, 2020 at 5:19 PM John Herrlin  wrote:
> >
> >>
> >> Hey Ian!
> >>
> >> Happy to see you as the maintainer of the ob-java!
> >>
> >> I would like to propose a feature to ob-java. The feature allows a
> >> source code block to write and compile only, without executing.
> >>
> >> Here is a common use case for me.
> >>
> >> Class without a entry point have an :compile-only header.
> >>
> >>#+HEADER: :classname se/my_test_package/Hey
> >>#+HEADER: :dir src
> >>#+HEADER: :compile-only t
> >>#+HEADER: :results none
> >>#+BEGIN_SRC java
> >>  package se.my_test_package;
> >>
> >>  public class Hey {
> >>  public static String hey(String name) {
> >>  return "Hey " + name;
> >>  }
> >>  }
> >>#+END_SRC
> >>
> >> The provided diff works for my small use case. What do you think?
> >>
> >> --
> >> Best regards
> >> John
> >>
> >>
>
>
> --
> Mvh John
>

Re: ob-java compile only

[ian martins]

Hi John,

Thanks for the suggestion and patch. Is the reason for this so that you can
have classes without needing dummy "main" methods?

Did you consider using org-babel-tangle to generate the source files? This
works for me:

Steps:
1. put javatangle.org (below) on your local.
2. create "pkg" directory where javatangle.org is
3. run org-babel-tangle on javatangle.org (this writes two source files to
the pkg dir)
4. run C-c C-c on the top source block (this compiles both source files and
runs main)

- javatangle.org -

#+begin_src java :results output :classname pkg/Main :tangle pkg/Main.java
  package pkg;

  public class Main {
  public static void main(String[] args) {
  System.out.println(Hey.hey());
  }
  }
#+end_src

#+begin_src java :results output :classname pkg/Hey :tangle pkg/Hey.java
  package pkg;

  public class Hey {
  public static String hey() {
  return "hey";
  }
  }
#+end_src



On Sun, Sep 27, 2020 at 5:19 PM John Herrlin  wrote:

>
> Hey Ian!
>
> Happy to see you as the maintainer of the ob-java!
>
> I would like to propose a feature to ob-java. The feature allows a
> source code block to write and compile only, without executing.
>
> Here is a common use case for me.
>
> Class without a entry point have an :compile-only header.
>
>#+HEADER: :classname se/my_test_package/Hey
>#+HEADER: :dir src
>#+HEADER: :compile-only t
>#+HEADER: :results none
>#+BEGIN_SRC java
>  package se.my_test_package;
>
>  public class Hey {
>  public static String hey(String name) {
>  return "Hey " + name;
>  }
>  }
>#+END_SRC
>
> The provided diff works for my small use case. What do you think?
>
> --
> Best regards
> John
>
>

Re: org-babel support for haxe

[ian martins]

with ob-java I assumed I shouldn't change ob-core, so I advised/overrode
ob-core instead of changing it. But it would be much better to change
ob-core. I'll submit those changes as a separate patch that modifies
ob-core.

On Sun, Sep 13, 2020 at 4:04 PM Kyle Meyer  wrote:

> ian martins writes:
>
> > ob-haxe and ob-java both involve a few changes to ob-core to allow temp
> > directories instead of just temp files. Should I submit that as a
> separate
> > patch?
>
> It looks like that change is included with your ob-java patch [0], which
> will be considered after 9.4 is released [1], so I think it's fine as
> is.  (In my opinion, splitting up that patch would have been nice, but I
> don't think it's worth a reroll, at least until some initial comments
> come in.)
>
> [0]
> https://orgmode.org/list/CAC=rjb7ahmnrq9nc4ao07qk3qzf4lvatmu_r1fwqr+97npn...@mail.gmail.com
> [1] https://orgmode.org/list/87sgbwgvx6@gnu.org
>

Re: org-babel support for haxe

[ian martins]

Thanks for the feedback. There's no special reason for the external test
data file or repeated executable-find calls. I was following the convention
from ob-C. I'll make those changes.

ob-haxe and ob-java both involve a few changes to ob-core to allow temp
directories instead of just temp files. Should I submit that as a separate
patch?

On Sun, Sep 6, 2020 at 11:24 AM Kyle Meyer  wrote:

> Hi ian,
>
> It looks like this library is instead going to be available through an
> ELPA, but FWIW here are a couple of comments on the tests.
>
> ian martins writes:
>
> > diff --git a/testing/examples/ob-haxe-test.org b/testing/examples/
> ob-haxe-test.org
> > new file mode 100644
> > index 0..ba9119d58
> > --- /dev/null
> > +++ b/testing/examples/ob-haxe-test.org
> > @@ -0,0 +1,247 @@
> > +#+Title: a collection of examples for ob-haxe tests
> > +#+OPTIONS: ^:nil
> > +* Simple
> > +  :PROPERTIES:
> > +  :ID:   966875e9-d10e-406c-9211-449555e3d3b2
> > +  :END:
> > +#+name: simple
> > +#+begin_src haxe :results output silent
> > +  Sys.print(42);
> > +#+end_src
>
> I know some other babel tests use a separate .org file, but I find this
> setup harder to follow compared to having the Org content within the
> test (e.g. using org-test-with-temp-text or
> org-test-with-temp-text-in-file).  Perhaps I'm missing why it's needed
> in this case though.
>
> > diff --git a/testing/lisp/test-ob-haxe.el b/testing/lisp/test-ob-haxe.el
> [...]
> > +;;; Code:
> > +(org-test-for-executable "haxe")
> > +(unless (featurep 'ob-haxe)
> > +  (signal 'missing-test-dependency "Support for haxe code blocks"))
> > +
> > +(ert-deftest ob-haxe/simple ()
> > +  "Hello world program."
> > +  (if (executable-find org-babel-haxe-command)
>
> I think you can avoid the executable-find here and in all the other
> tests because you have (org-test-for-executable "haxe") at the beginning
> of the file.
>

Re: Babel: parse error when output contains opening bracket

[ian martins]

Of course there's never a problem in fixing things. I'm curious how you did
it. Will look when I have a chance.

On Sun, Sep 6, 2020, 5:57 AM Bastien  wrote:

> Hi Ian,
>
> ian martins  writes:
>
> > I've written an alternative org-java.el that doesn't have that
> > problem.
>
> I hope you don't mind the fix I just integrated -- it's simple
> enough for being in 9.3.8, the next stable release.  Obviously
> your updates ob-java.el will probably make it obsolete once
> we can move on after 9.4.
>
> Thanks,
>
> --
>  Bastien
>

Re: ob-java and ob-haxe

[ian martins]

It primarily adds features.

It fixes the problem reported here [1] but that's probably not a common
problem and the person who reported it probably already migrated.

[1] https://orgmode.org/list/87d05nidu1@iki.fi/

On Sat, Sep 5, 2020 at 9:04 AM Bastien  wrote:

> Hi Ian,
>
> ian martins  writes:
>
> > Sure, I'd be happy to maintain ob-java.
>
> Thanks!  Does your work on ob-java.el fix bugs or does it foremost
> add new features?  If the former, we can add it now to master, then
> add you as a maintainer immediately.
>
> > The drawback with keeping ob-haxe in an external repo is that the
> > tests won't run when org-mode is changed, but in practice its tests
> > are very similar to ob-java's so the actual risk of it being broken
> > by a change will be small if ob-java is in core.
> >
> > I'll submit ob-haxe to GNU ELPA after ob-java has been accepted. That
> > way I can take out the common parts of ob-haxe which will have been
> > incorporated into ob-core.
>
> Yes -- for now (< 9.4) we cannot accept changes in ob-core.el.
>
> Thanks,
>
> --
>  Bastien
>

Re: org-babel support for haxe

[ian martins]

That makes sense.

It's probably enough to keep the languages page [1] complete and up to
date. External repos should already have docs with the code.

[1] https://orgmode.org/worg/org-contrib/babel/languages.html


On Sat, Sep 5, 2020 at 3:24 AM Bastien  wrote:

> Hi Ian,
>
> ian martins  writes:
>
> > Hello. The included patch adds org-babel support for haxe (https://
> > haxe.org/). It allows main class and function definitions to be
> > optional, accepts variables and supports babel functional mode.
> > Please review.
>
> I'm not an Haxe user, so I cannot review the functionnalities, but
> from a cursory look, it seems fine.
>
> After 9.4, we will probably remove some Babel libraries from Org's
> core: we still need to decide on what criterium, but one candidate
> is to remove a Babel library if the corresponding language is not
> supported within Emacs core itself.
>
> If we go that route, we also need to do a better job at promoting
> external Babel libraries: perhaps a page on https://orgmode.org/worg
> would help.
>
> 2 cents,
>
> --
>  Bastien
>

Re: ob-java and ob-haxe

[ian martins]

Hi Bastien,

Sure, I'd be happy to maintain ob-java.

The drawback with keeping ob-haxe in an external repo is that the tests
won't run when org-mode is changed, but in practice its tests are very
similar to ob-java's so the actual risk of it being broken by a change will
be small if ob-java is in core.

I'll submit ob-haxe to GNU ELPA after ob-java has been accepted. That way I
can take out the common parts of ob-haxe which will have been incorporated
into ob-core.


On Fri, Sep 4, 2020 at 5:50 AM Bastien  wrote:

> Hi Ian,
>
> thanks for your work on this.  Changes for ob-java.el should go in
> core after the 9.4 release.  By the way, if you want to be ob-java.el
> maintainer, that'd be appreciated too!
>
> For ob-haxe.el, as Kyle suggests, let's prefer GNU ELPA (or upcoming
> Non-GNU ELPA): Elisp files in contrib/ will be exfiltrated after 9.4.
>
> Thanks,
>
> --
>  Bastien
>

Re: ob-java and ob-haxe

[ian martins]

That is understandable; they're big patches. I recommend going over ob-java
first. Java is probably more familiar to you and ob-java and ob-haxe are
very similar. These were mostly based on ob-python and ob-C. The tests are
based on ob-Cs tests.

Look carefully at org-babel-temp-dir and
org-babel-remove-temporary-directory. The patches override core but ideally
these would be changes in core.

I was hesitant to put these in ELPA because then the tests won't run when
org-mode is modified.


On Thu, Sep 3, 2020 at 12:56 AM Kyle Meyer  wrote:

> ian martins writes:
>
> > I posted patches for ob-java and ob-haxe a couple months ago but there
> was
> > no interest. I have been given access to push to contrib. If there's no
> > objection I'll put them there.
> >
> > I'll rename my version ob-java-alt so it doesn't conflict with the
> official
> > one. The contrib directory doesn't have a "testing" directory so I'll add
> > one. I'll document them in worg.
>
> My understanding is that there's been a move away from adding new
> libraries to contrib/, instead preferring an ELPA for cases where core
> isn't deemed appropriate.
>
> Fixes and enhancements to ob-java are obviously appropriate for core.
> And while it'd be fine to host ob-haxe separately, my impression is that
> it too would be suitable for core.
>
> I'm sorry your patches haven't gotten any reviews or other feedback.
> I've sat down a couple of times to review the ob-haxe patch but haven't
> ended up blocking off enough time to get anywhere.  I'll revisit it this
> weekend.  Of course, any feedback from those that actually use haxe
> would be appreciated.
>
>

ob-java and ob-haxe

[ian martins]

I posted patches for ob-java and ob-haxe a couple months ago but there was
no interest. I have been given access to push to contrib. If there's no
objection I'll put them there.

I'll rename my version ob-java-alt so it doesn't conflict with the official
one. The contrib directory doesn't have a "testing" directory so I'll add
one. I'll document them in worg.

-Ian

Re: [SUSPECTED SPAM]New package: Org Pandoc Import

[ian martins]

I'll have to take a closer look, but at a glance I think I'll be using this
every day from now on. I interact with three wiki formats frequently at
work. I'd written a few helpers to convert tables back and forth but mostly
resort to writing in those markups or exporting to markdown and hand
converting. This will be a big help. Thanks!

On Sat, Aug 15, 2020, 3:30 PM TEC  wrote:

> Hi Everyone,
>
> I've just pushed the initial version of a package I think is pretty nifty
> (no
> bias here ;) and thought it might me nice to mention it to the mailing
> list.
>
> https://github.com/tecosaur/org-pandoc-import
>
> This leverages Pandoc to reduce my interaction with other formats.
> Hopefully
> it's of interest to a few of you :)
>
> Enjoy!
>
> Timothy.
>
>

Re: Using Code Block for C++

[ian martins]

Christopher,

C, C++ and D are all defined in ob-C.el, so when you load C you get C++ and
D as well. If you remove the "(c++ . t)" from the above line, does it work?


On Wed, Aug 5, 2020 at 6:05 PM Christopher Dimech  wrote:

>
> Have been trying to set the C++ call for using a code block.
>
> Here is the call. I am getting an error, have tried Cpp, cpp, C++, c++
>
>   (org-babel-do-load-languages
> 'org-babel-load-languages
> '( (sh . t) (lisp . t) (emacs-lisp . t)
>(awk . t) (python . t) (R . t)
>(C . t) (c++ . t) (F90 . t)
>   ))
>
> The error is
>
> Debugger entered--Lisp error: (file-error "Cannot open load file" "ob-c++")
>   require(ob-c++)
>
> -
> Christopher Dimech
> Chief Administrator - Naiad Informatics - GNU Project (Geocomputation)
> - Geophysical Simulation
> - Geological Subsurface Mapping
> - Disaster Preparedness and Mitigation
> - Natural Resource Exploration and Production
> - Free Software Advocacy
>
>
>

Re: Why is Babel-C trimming its output?

[ian martins]

That's up to the maintainers.

If you just want to fix it on your end you could advise/replace
`org-babel-C-execute` but unfortunately there's a lot there.

On Fri, Jul 17, 2020, 1:31 PM Michaël Cadilhac 
wrote:

> Thanks for the investigation Ian.  So, since the tests run just fine
> without it, and it offers an inconsistent and at times detrimental
> feature, can we consider removing it, and/or adding some options for
> that?
>
> I'd be fine having to flag my src-block with a ":verbatim t" option to
> make sure that the output is not mangled.
>
> Thoughts?
>
> On Fri, Jul 17, 2020 at 7:30 AM ian martins  wrote:
> >
> > Fortunately the author wrote tests, so we can tie the behavior of the
> code to use cases. Unfortunately all the tests pass with the call to
> org-trim removed. Also the call is there from the first commit of the file
> in git, so there's no commit message to explain.
> >
> > My guess is that it was added to clean up cases that resulted in extra
> trailing whitespace, but I dunno.
> >
> >
> > On Wed, Jul 15, 2020 at 7:12 PM Michaël Cadilhac 
> wrote:
> >>
> >> Hello,
> >>
> >> Quick question here: in ob-C.el, before returning the output of a C
> >> file, there's this line:
> >>
> >> (setq results (org-trim (org-remove-indentation results)))
> >>
> >> That seems quite arbitrary; is it on purpose?  I have a C file that
> >> outputs some sort of list of formatted numbers, e.g.:
> >>
> >>   0  -17.8
> >>  404.4
> >>  80   26.7
> >> 120   48.9
> >>
> >> and only the first line gets trimmed, leading to a faulty output.
> >>
> >> This does not seem to be a universal thing in Babel; for instance:
> >>
> >> #+begin_src emacs-lisp :exports both :results value raw
> >>   " 0\n 1\n2\n"
> >> #+end_src
> >>
> >> …results in:
> >>
> >> #+RESULTS:
> >>  0
> >>  1
> >> 2
> >>
> >> But the same thing in C:
> >>
> >> #+begin_src C :exports both :results output raw
> >>   printf (" 0\n 1\n2\n");
> >> #+end_src
> >>
> >> …results in:
> >> #+RESULTS:
> >> 0
> >>  1
> >> 2
> >>
> >> Cheers,
> >> M.
> >>
>

Re: Why is Babel-C trimming its output?

[ian martins]

Fortunately the author wrote tests, so we can tie the behavior of the code
to use cases. Unfortunately all the tests pass with the call to org-trim
removed. Also the call is there from the first commit of the file in git,
so there's no commit message to explain.

My guess is that it was added to clean up cases that resulted in extra
trailing whitespace, but I dunno.


On Wed, Jul 15, 2020 at 7:12 PM Michaël Cadilhac 
wrote:

> Hello,
>
> Quick question here: in ob-C.el, before returning the output of a C
> file, there's this line:
>
> (setq results (org-trim (org-remove-indentation results)))
>
> That seems quite arbitrary; is it on purpose?  I have a C file that
> outputs some sort of list of formatted numbers, e.g.:
>
>   0  -17.8
>  404.4
>  80   26.7
> 120   48.9
>
> and only the first line gets trimmed, leading to a faulty output.
>
> This does not seem to be a universal thing in Babel; for instance:
>
> #+begin_src emacs-lisp :exports both :results value raw
>   " 0\n 1\n2\n"
> #+end_src
>
> …results in:
>
> #+RESULTS:
>  0
>  1
> 2
>
> But the same thing in C:
>
> #+begin_src C :exports both :results output raw
>   printf (" 0\n 1\n2\n");
> #+end_src
>
> …results in:
> #+RESULTS:
> 0
>  1
> 2
>
> Cheers,
> M.
>
>

Re: Superscript and non-blank character

[ian martins]

Bo, you can try this. I don't know what else it will break, so I did it as
a file local. alternatively you could set `org-match-substring-regexp' in
your init.

---
;;; -*- org-match-substring-regexp:
"\\(\\)\\([_^]\\)\\(\\(?:{\\([^{}]*?\\|\\(?:[^{}]*?{[^{}]*?}\\)+[^{}]*?\\|\\(?:[^{}]*?{\\(?:[^{}]*?{[^{}]*?}\\)+[^{}]*?}\\)+[^{}]*?\\)}\\)\\|\\(?:(\\([^()]*?\\|\\(?:[^()]*?([^()]*?)\\)+[^()]*?\\|\\(?:[^()]*?(\\(?:[^()]*?([^()]*?)\\)+[^()]*?)\\)+[^()]*?\\))\\)\\|\\(?:\\*\\|[+-]?[[:alnum:].,\\]*[[:alnum:]]\\)\\)";
org-pretty-entities: t; -*-

here are some verses where there's a space after the verse number:

^1 In the beginning God created the heavens and the earth. ^2 Now the earth
was formless and empty, darkness was over the surface of the deep, and the
Spirit of God was hovering over the waters.

if you don't want the space after the verse number, you can use curlys:

^{3}And God said, “Let there be light,” and there was light. ^{4}God saw
that the light was good, and he separated the light from the darkness.
^{5}God called the light “day,” and the darkness he called “night.” And
there was evening, and there was morning—the first day.

On Fri, Jul 10, 2020 at 8:33 PM Bo Grimes  wrote:

> Emacs 26.3, Org-mode 9.1.9, Kubuntu 20.04, 5.4.0-39-generic
>
> Hi,
>
> I've tried my hardest to find an answer in the manuals (print book and
> on-line), this list, Reddit, and Stack Exchange with no luck.  I use Emacs
> for org-mode, and I don't code or know Elisp.  I have no use for or
> interest in learning LaTeX.  I never use subscript, and I only use
> superscript in poetry/prose (mostly quotes, not original), and I don't
> foresee (but admit I may) a need to export.
>
> I understand that:
>
> ^2H is not recognized as superscript _on purpose_. Per Org syntax, you
> have to add a non-blank character before the caret. Otherwise, there would
> be ambiguity between underline (e.g., _under_) and subscript (_under). And
> superscript syntax follows subscript's. [1]
>
> That makes sense to me as a default [2], given that so many org-mode users
> use both in math, science, and literate coding context, so I wouldn't think
> to suggest it to be changed.  All I want to know is how I can change it for
> *me*.
>
> I would like to org-toggle-pretty-entities in a buffer and see superscript
> before, say, a poetry line or Bible verse I'm quoting in a note or journal
> entry, and not see the non-blank character.
>
> Can this be done via customize or with an Elisp snippet in init.el?
>
> Thanks!
>
> [1] https://lists.gnu.org/archive/html/emacs-orgmode/2014-06/msg01022.html
>
> [2] Though I wish it were made explicit in the manuals
> https://orgmode.org/manual/Subscripts-and-Superscripts.html#Subscripts-and-Superscripts
> (Org Mode 9 Reference Manual p 132). It took me a while to figure out why
> it wasn't working at all.
>
>
>

Re: Bug: org-babel python with :results value sends function definition with a statement after a for loop to the shell incorrectly [9.3.6 (9.3.6-elpa @ /home/username/.emacs.d/elpa/org-9.3.6/)]

[ian martins]

I was able to reproduce the error. I started emacs without my init file
(emacs -q) and then

,
| (add-to-list 'load-path "~/code/elisp/org-mode/lisp")
| (require 'ob-python)
| (org-babel-do-load-languages 'org-babel-load-languages `((python . t)))
`

in scratch, and then ran your test. I got the same errors you described. I
redid the test but loaded the lastest org-mode and there was no error. This
means you probably don't need to debug this. It has been fixed in the
latest version, but the fix hasn't been updated in the elpa package yet.
you can either wait for the next release or pull the latest code from the
repo.

On Mon, Jul 6, 2020 at 3:18 PM Philip Blagoveschensky 
wrote:

> Hi Ian,
>
>  >Do you have the same issue if you aren't using a session?
>
> If I run the following code block (this time I am using python 3, so
> there are parens in the print line)
>
> #+begin_src python
> def foobar():
>  for i in range(5):
>  pass
>  print("hello world")
>  return 3
>
> return foobar()
> #+end_src
>
> I get
>
> #+RESULTS:
> : 3
>
> so I know it worked fine.
>
> But if I add session like this:
>
> #+begin_src python :session bug_report
> def foobar():
>  for i in range(5):
>  pass
>  print("hello world")
>  return 3
>
> return foobar()
> #+end_src
>
> then in *bug_report* I get
>
>  >>> def foobar():
> ... for i in range(5):
> ... pass
> ...
>  >>> print("hello world")
>File "", line 1
>  print("hello world")
>  ^
> IndentationError: unexpected indent
>  return 3
>  >>>
>File "", line 1
>  return 3
>  ^
> IndentationError: unexpected indent
>  >>> return foobar()
>  >>>
>File "", line 1
> SyntaxError: 'return' outside function
>  >>> open('/tmp/babel-D0mRnD/python-CJ6UtT', 'w').write(str(_))
>  >>>
> 20
>  >>>
>  >>> 'org_babel_python_eoe'
>  >>> 'org_babel_python_eoe'
>  >>>
>
>  >Are you using tabs or spaces?
>
> I used spaces. 4 spaces per indentation level, to be exact.
>
> Also, FYI, as it might be relevant information, the shell buffer
> contents I posted above happen if the session has been created
> previously. If, instead, this is the first time I run some code in this
> session, then I also get another error - NameError (see below). Below
> you can see the contents of *bug_report* buffer if I run this code cell
> in a not-yet-existing session.
>
> def foobar():
> Python 3.8.2 | packaged by conda-forge | (default, Mar  5 2020, 17:11:00)
> [GCC 7.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> ... for i in range(5):
> ... pass
> ...
>  >>> print("hello world")
>File "", line 1
>  print("hello world")
>  ^
> IndentationError: unexpected indentreturn 3
>
>  >>>
>File "", line 1
>  return 3
>  ^
> IndentationError: unexpected indent
>  >>> return foobar()
>  >>>
>File "", line 1
> SyntaxError: 'return' outside function
>  >>> open('/tmp/babel-D0mRnD/python-MsDjEk', 'w').write(str(_))
>  >>>
> Traceback (most recent call last):
>File "", line 1, in 
> NameError: name '_' is not defined
>  >>>
>  >>> 'org_babel_python_eoe'
>  >>> 'org_babel_python_eoe'
>  >>>
>
> If you have a suggestion on how to debug this, feel free to tell.
>

Re: Bug: org-babel python with :results value sends function definition with a statement after a for loop to the shell incorrectly [9.3.6 (9.3.6-elpa @ /home/username/.emacs.d/elpa/org-9.3.6/)]

[ian martins]

Hello Philip,

I tested again and still can't reproduce the issue.  ob-python doesn't
change the indentation between individual lines of a code block, so this is
strange. Do you have the same issue if you aren't using a session? Are you
using tabs or spaces? (I tested with spaces)

On Sun, Jul 5, 2020 at 7:37 AM Philip Blagoveschensky 
wrote:

> Consider the following org-babel block:
>
>
>
> #+begin_src python :session bug_report
> def foobar():
>  for i in range(5):
>  pass
>  print "hello world"
>
> foobar()
> #+end_src
>
>
>
> When I run it, this is what I see in the *bug_report* buffer:
>
>
>
> def foobar():
> ... for i in range(5):
> ... pass
> ...
>  >>> print "hello world"
>File "", line 1
>  print "hello world"
>  ^
> IndentationError: unexpected indent
>
>  >>> foobar()
>  >>>
>  >>> open('/tmp/babel-MOOCF9/python-UW5PEF', 'w').write(str(_))
>  >>>
>  >>>
>  >>> 'org_babel_python_eoe'
>  >>> 'org_babel_python_eoe'
>  >>>
>
>
>
> So, org-babel incorrectly decided that the line with the print is not a
> part of the function's definition and sent it to Python shell as a
> separate statement. Instead, it should've sent it as a part of foobar's
> definition.
>
> This problem persists
> - If I use python3 instead of python2
> - If I replace
>  print "hello world"
>with
>  return 42
>
> This problem disappears if I add :results output to the source block.
>
>
> Emacs  : GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
>   of 2019-09-23, modified by Debian
> Package: Org mode version 9.3.6 (9.3.6-elpa @
> /home/username/.emacs.d/elpa/org-9.3.6/)
>
>
> current state:
> ==
> (setq
>   org-src-mode-hook '(org-src-babel-configure-edit-buffer
>  org-src-mode-configure-edit-buffer)
>   org-link-shell-confirm-function 'yes-or-no-p
>   org-metadown-hook '(org-babel-pop-to-session-maybe)
>   org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
>   org-mode-hook '(#[0 "\300\301\302\303\304$\207"
>[add-hook change-major-mode-hook org-show-all append
> local]
>5]
>  #[0 "\300\301\302\303\304$\207"
>[add-hook change-major-mode-hook
> org-babel-show-result-all append local]
>5]
>  org-babel-result-hide-spec org-babel-hide-all-hashes)
>   org-archive-hook '(org-attach-archive-delete-maybe)
>   org-confirm-elisp-link-function 'yes-or-no-p
>   org-agenda-before-write-hook '(org-agenda-add-entry-text)
>   org-metaup-hook '(org-babel-load-in-session-maybe)
>   org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
> "\n\n(fn ENTRY)"]
>   org-babel-pre-tangle-hook '(save-buffer)
>   org-tab-first-hook '(org-babel-hide-result-toggle-maybe
>   org-babel-header-arg-expand)
>   org-babel-load-languages '((emacs-lisp . t) (python . t))
>   org-occur-hook '(org-first-headline-recenter)
>   org-cycle-hook '(org-cycle-hide-archived-subtrees
>   org-cycle-show-empty-lines
>   org-optimize-window-after-visibility-change)
>   org-speed-command-hook '(org-speed-command-activate
>   org-babel-speed-command-activate)
>   org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el")
>   ("elisp" . "el"))
>   org-confirm-shell-link-function 'yes-or-no-p
>   org-link-parameters '(("attachment" :follow org-attach-open-link :export
> org-attach-export-link :complete
> org-attach-complete-link)
>("id" :follow org-id-open)
>("eww" :follow eww :store org-eww-store-link)
>("rmail" :follow org-rmail-open :store
> org-rmail-store-link)
>("mhe" :follow org-mhe-open :store
> org-mhe-store-link)
>("irc" :follow org-irc-visit :store
> org-irc-store-link :export org-irc-export)
>("info" :follow org-info-open :export
> org-info-export :store org-info-store-link)
>("gnus" :follow org-gnus-open :store
> org-gnus-store-link)
>("docview" :follow org-docview-open :export
> org-docview-export :store org-docview-store-link)
>("bibtex" :follow org-bibtex-open :store
> org-bibtex-store-link)
>("bbdb" :follow org-bbdb-open :export
> org-bbdb-export :complete org-bbdb-complete-link
> :store org-bbdb-store-link)
>("w3m" :store org-w3m-store-link) ("file+sys")
>("file+emacs")
>("shell" :follow org-link--open-shell)
>

Re: Bug: org-babel python with :results value sends function definition with a statement after a for loop to the shell incorrectly [9.3.6 (9.3.6-elpa @ /home/username/.emacs.d/elpa/org-9.3.6/)]

[ian martins]

your example works for me without any changes. "return 42" works as well.
it returns None and there are no errors in the *bug_report* buffer.

I'm using:
GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.21) of 2017-09-22,
modified by Debian
Org mode version 9.3.6 (release_9.3.6-739-g0c1740.dirty @
/home/ian/code/elisp/org-mode/lisp/)

On Wed, Jul 1, 2020 at 12:57 PM Philip Blagoveschensky 
wrote:

> Consider the following org-babel block:
>
>
>
> #+begin_src python :session bug_report
> def foobar():
>  for i in range(5):
>  pass
>  print "hello world"
>
> foobar()
> #+end_src
>
>
>
> When I run it, this is what I see in the *bug_report* buffer:
>
>
>
> def foobar():
> ... for i in range(5):
> ... pass
> ...
> >>> print "hello world"
>File "", line 1
>  print "hello world"
>  ^
> IndentationError: unexpected indent
>
> >>> foobar()
> >>>
> >>> open('/tmp/babel-MOOCF9/python-UW5PEF', 'w').write(str(_))
> >>>
> >>>
> >>> 'org_babel_python_eoe'
> >>> 'org_babel_python_eoe'
> >>>
>
>
>
> So, org-babel incorrectly decided that the line with the print is not a
> part of the function's definition and sent it to Python shell as a
> separate statement. Instead, it should've sent it as a part of foobar's
> definition.
>
> This problem persists
> - If I use python3 instead of python2
> - If I replace
>  print "hello world"
>with
>  return 42
>
> This problem disappears if I add :results output to the source block.
>
>
> Emacs  : GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
>   of 2019-09-23, modified by Debian
> Package: Org mode version 9.3.6 (9.3.6-elpa @
> /home/username/.emacs.d/elpa/org-9.3.6/)
>
>
> current state:
> ==
> (setq
>   org-src-mode-hook '(org-src-babel-configure-edit-buffer
>  org-src-mode-configure-edit-buffer)
>   org-link-shell-confirm-function 'yes-or-no-p
>   org-metadown-hook '(org-babel-pop-to-session-maybe)
>   org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
>   org-mode-hook '(#[0 "\300\301\302\303\304$\207"
>[add-hook change-major-mode-hook org-show-all append
> local]
>5]
>  #[0 "\300\301\302\303\304$\207"
>[add-hook change-major-mode-hook
> org-babel-show-result-all append local]
>5]
>  org-babel-result-hide-spec org-babel-hide-all-hashes)
>   org-archive-hook '(org-attach-archive-delete-maybe)
>   org-confirm-elisp-link-function 'yes-or-no-p
>   org-agenda-before-write-hook '(org-agenda-add-entry-text)
>   org-metaup-hook '(org-babel-load-in-session-maybe)
>   org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
> "\n\n(fn ENTRY)"]
>   org-babel-pre-tangle-hook '(save-buffer)
>   org-tab-first-hook '(org-babel-hide-result-toggle-maybe
>   org-babel-header-arg-expand)
>   org-babel-load-languages '((emacs-lisp . t) (python . t))
>   org-occur-hook '(org-first-headline-recenter)
>   org-cycle-hook '(org-cycle-hide-archived-subtrees
>   org-cycle-show-empty-lines
>   org-optimize-window-after-visibility-change)
>   org-speed-command-hook '(org-speed-command-activate
>   org-babel-speed-command-activate)
>   org-babel-tangle-lang-exts '(("python" . "py") ("emacs-lisp" . "el")
>   ("elisp" . "el"))
>   org-confirm-shell-link-function 'yes-or-no-p
>   org-link-parameters '(("attachment" :follow org-attach-open-link :export
> org-attach-export-link :complete
> org-attach-complete-link)
>("id" :follow org-id-open)
>("eww" :follow eww :store org-eww-store-link)
>("rmail" :follow org-rmail-open :store
> org-rmail-store-link)
>("mhe" :follow org-mhe-open :store
> org-mhe-store-link)
>("irc" :follow org-irc-visit :store
> org-irc-store-link :export org-irc-export)
>("info" :follow org-info-open :export
> org-info-export :store org-info-store-link)
>("gnus" :follow org-gnus-open :store
> org-gnus-store-link)
>("docview" :follow org-docview-open :export
> org-docview-export :store org-docview-store-link)
>("bibtex" :follow org-bibtex-open :store
> org-bibtex-store-link)
>("bbdb" :follow org-bbdb-open :export
> org-bbdb-export :complete org-bbdb-complete-link
> :store org-bbdb-store-link)
>("w3m" :store org-w3m-store-link) ("file+sys")
>("file+emacs")
>  

Re: Babel: parse error when output contains opening bracket

[ian martins]

On Tue, Jun 30, 2020 at 12:13 AM Jarmo Hurri  wrote:

> ian martins  writes:
>
> > Since you recommend it, I will try submitting a patch for java.
>
> Excellent.
>

I posted the patch
<https://orgmode.org/list/CAC=rjb7ahmnrq9nc4ao07qk3qzf4lvatmu_r1fwqr+97npn...@mail.gmail.com/T/#u>
for java.  Let me know if you have feedback.


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

haxe <https://haxe.org/> is a language. By haxe integration I meant that I
wrote an ob-haxe.el to use haxe code blocks in org.

-Ian

[PATCH] ob-java support for variables, functional mode, tramp, add tests

[ian martins]

Hello. Attached is a patch to update the ob-java.el implementation. This
allows package, class and imports to be provided in the code or header
arguments or omitted, accepts variables, supports functional mode (:results
value), writes temp files to the temp directory instead of current dir,
works with tramp, and adds tests.

The "writes temp files to the temp directory" forced changes in ob-core in
order to write and delete directories to the temp directory.

Please review.
Ian
From 3d66247e3aabead7cf1bda4930f0b7a84e3ee324 Mon Sep 17 00:00:00 2001
From: Ian Martins 
Date: Sun, 28 Jun 2020 19:27:08 -0400
Subject: [PATCH] Update ob-java to allow functional mode, accept variables,
 work with tramp, etc

* ob-core.el (org-babel-temp-file,
org-babel-remove-temporary-directory): Create and remove temp
directories.
* ob-java.el: Add support for functional mode, variables, make class
and main method definitions optional, write files in temporary
directory, work with tramp.
* ob-java-test.org: New test data.
* test-ob-java.el: New tests.

Java requires source files names and directories to match their class
and package names.  The old implementation wrote these directories and
files in the current directory.  We move these files to the temporary
directory to work with tramp and avoid polluting the current
directory.  In order to move these files to the temporary directory we
have to modify ob-core to write and remove diretories.
---
 lisp/ob-core.el   |  55 ++---
 lisp/ob-java.el   | 340 ++
 testing/examples/ob-java-test.org | 310 +++
 testing/lisp/test-ob-java.el  | 294 ++
 4 files changed, 932 insertions(+), 67 deletions(-)
 create mode 100644 testing/examples/ob-java-test.org
 create mode 100644 testing/lisp/test-ob-java.el

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index e798595bd..4c22522e3 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -3078,17 +3078,17 @@ Emacs shutdown."))
 	   ,@table-forms)
 (def-edebug-spec org-babel-result-cond (form form body))
 
-(defun org-babel-temp-file (prefix  suffix)
+(defun org-babel-temp-file (prefix  suffix dir-flag)
   "Create a temporary file in the `org-babel-temporary-directory'.
-Passes PREFIX and SUFFIX directly to `make-temp-file' with the
-value of `temporary-file-directory' temporarily set to the value
-of `org-babel-temporary-directory'."
+Passes PREFIX, SUFFIX and DIR-FLAG directly to `make-temp-file'
+with the value of `temporary-file-directory' temporarily set to
+the value of `org-babel-temporary-directory'."
   (if (file-remote-p default-directory)
   (let ((prefix
  (concat (file-remote-p default-directory)
  (expand-file-name
 		  prefix org-babel-remote-temporary-directory
-(make-temp-file prefix nil suffix))
+(make-temp-file prefix dir-flag suffix))
 (let ((temporary-file-directory
 	   (or (and (boundp 'org-babel-temporary-directory)
 		(file-exists-p org-babel-temporary-directory)
@@ -3099,25 +3099,32 @@ of `org-babel-temporary-directory'."
 (defun org-babel-remove-temporary-directory ()
   "Remove `org-babel-temporary-directory' on Emacs shutdown."
   (when (and (boundp 'org-babel-temporary-directory)
-	 (file-exists-p org-babel-temporary-directory))
-;; taken from `delete-directory' in files.el
-(condition-case nil
-	(progn
-	  (mapc (lambda (file)
-		  ;; This test is equivalent to
-		  ;; (and (file-directory-p fn) (not (file-symlink-p fn)))
-		  ;; but more efficient
-		  (if (eq t (car (file-attributes file)))
-		  (delete-directory file)
-		(delete-file file)))
-		(directory-files org-babel-temporary-directory 'full
- directory-files-no-dot-files-regexp))
-	  (delete-directory org-babel-temporary-directory))
-  (error
-   (message "Failed to remove temporary Org-babel directory %s"
-		(if (boundp 'org-babel-temporary-directory)
-		org-babel-temporary-directory
-		  "[directory not defined]"))
+ (file-exists-p org-babel-temporary-directory))
+;; This is equivalent to "rm -rf * dir" so we should be really
+;; sure `dir' isn't /.  This is made safer but more brittle by
+;; filtering the first level files by the emacs tmpfile format.
+(if (< (length org-babel-temporary-directory) 3)
+(message (concat "Not deleting babel temp subdirectories since "
+ "`babel-temporary-directory' doesn't appear "
+ "to be set to a temporary directory."))
+  ;; taken from `delete-directory' in files.el
+  (condition-case nil
+  (progn
+(mapc (lambda (file)
+;; This test is equivalent to
+;; (and (file-directory-p fn) (not (file-symlink-p fn)))
+;; but more effic

Re: Babel: parse error when output contains opening bracket

[ian martins]

A little while back I submitted a patch to add org-babel integration for
haxe and mentioned that the same could be done for java to expand the
features of the java integration. There was no response which I took to
mean no interest in haxe or java, so I didn't think submitting a patch for
java would be fruitful. Then I thought I could just add them to the contrib
directory but was mistaken since that goes through the same ML patch
workflow.

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

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

-Ian

On Sun, Jun 28, 2020 at 1:55 AM Jarmo Hurri  wrote:

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

[ian martins]

On Sat, Jun 27, 2020 at 1:25 AM Jarmo Hurri  wrote:

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


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


>
> How does that sound?
>
> Jarmo
>
>
>

Re: Babel: parse error when output contains opening bracket

[ian martins]

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.

On Thu, Jun 25, 2020 at 7:29 AM Jarmo Hurri  wrote:

>
> 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: Not working ob-C sample code

[ian martins]

Maybe you could use the C compiler instead of C++, or you could include the
c libraries you need. try these options:

#+begin_src C :var somedata=somedata

#+begin_src C++ :var somedata=somedata :includes '( 
)

On Mon, Jun 22, 2020 at 8:56 PM Naoya Yamashita  wrote:

> Hi! I'm Naoya. This is the first mail to this ML.
>
> First, thank you for developing such awesome packages!
>
> I found ob-C sample[1] is not working for me, I report that to this ML.
>
> [1]:
> https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-C.org.html
>
> ## Repro step
> 1. Require org and ob-C.
> 2. Write below in some org buffer.
> ```org
> #+tblname: somedata
> | nb| sqr | noise |
> |---+-+---|
> | zero  |   0 |  0.23 |
> | one   |   1 |  1.31 |
> | two   |   4 |  4.61 |
> | three |   9 |  9.05 |
> | four  |  16 | 16.55 |
>
> #+name: c-table
> #+header: :exports results
> #+begin_src C++ :var somedata=somedata
>   int main()
>   {
> for (int i=0; i   printf ("%2d %7s ", i, somedata_h(i,"nb"));
>   for (int j=1; j const char* cell = somedata[i][j];
> printf ("%5s %5g ", cell, 1000*atof(cell));
>   }
>   printf("\n");
> }
> return 0;
>   }
> #+end_src
> ```
> 3. Babel src block via C-c C-c.
> 4. Error occurred.  I get below error output
> ```
> /tmp/babel-kMPbac/C-src-KDQDdx.cpp: In function ‘int get_column_num(int,
> const char**, const char*)’:
> /tmp/babel-kMPbac/C-src-KDQDdx.cpp:17:9: error: ‘strcmp’ was not declared
> in this scope
>17 | if (strcmp(header[c],column)==0)
>   | ^~
> /tmp/babel-kMPbac/C-src-KDQDdx.cpp:1:1: note: ‘strcmp’ is defined in
> header ‘’; did you forget to ‘#include ’?
>   +++ |+#include 
> 1 |
> /tmp/babel-kMPbac/C-src-KDQDdx.cpp: In function ‘int main()’:
> /tmp/babel-kMPbac/C-src-KDQDdx.cpp:27:5: error: ‘printf’ was not declared
> in this scope
>27 | printf ("%2d %7s ", i, somedata_h(i,"nb"));
>   | ^~
> /tmp/babel-kMPbac/C-src-KDQDdx.cpp:1:1: note: ‘printf’ is defined in
> header ‘’; did you forget to ‘#include ’?
>   +++ |+#include 
> 1 |
> /tmp/babel-kMPbac/C-src-KDQDdx.cpp:30:38: error: ‘atof’ was not declared
> in this scope
>30 |   printf ("%5s %5g ", cell, 1000*atof(cell));
>   |  ^~~~
> zsh:1: permission denied: /tmp/babel-kMPbac/C-bin-EfCzWt
> ```
>
> ## Some note
> - These errors caused because a lack to include some library.
>   - Add some include statement generate and insert it in
> `org-babel-C-utility-header-to-C`?
>   - Add new option for a user preamble and insert it in
> `org-babel-C-expand-C`?
>
> Regards,
>

org-babel support for haxe

[ian martins]

Hello. The included patch adds org-babel support for haxe (https://haxe.org/).
It allows main class and function definitions to be optional, accepts
variables and supports babel functional mode. Please review.

I believe the same approach should work for java also. If this is fine I
could try to write an ob-java based on this to give java the same features
listed above.

One thing I would like to change is that this dumps the generated source
files in the current directory instead of burying them in the babel temp
dir (org-babel-temporary-directory). The same applies to the current
ob-java implementation. In order to put the temp source files in the babel
temp dir, there would have to be changes made in ob-core to allow creation
and removal of directories in the babel temp dir. If that seems reasonable
then I could try doing it, but let me know if there are reasons not to or
complications that I haven't thought of.

I've not done the FSF release. If this is acceptable I understand that I'll
have to do that.

-Ian
diff --git a/lisp/ob-haxe.el b/lisp/ob-haxe.el
new file mode 100644
index 0..5b0a42c7a
--- /dev/null
+++ b/lisp/ob-haxe.el
@@ -0,0 +1,260 @@
+;;; ob-haxe.el --- org-babel functions for haxe evaluation
+
+;; Copyright (C) 2020 Free Software Foundation, Inc.
+
+;; Author: Ian Martins
+;; Keywords: literate programming, reproducible research
+;; Homepage: http://orgmode.org
+
+;; This file is not part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;; Org-Babel support for evaluating haxe source code.
+
+;;; Code:
+(require 'ob)
+
+(defvar org-babel-tangle-lang-exts)
+(add-to-list 'org-babel-tangle-lang-exts '("haxe" . "hx"))
+
+(defvar org-babel-default-header-args:haxe '()
+  "Default header args for haxe source blocks.")
+
+(defconst org-babel-header-args:haxe '((target . '(interp neko hashlink))
+   (imports . :any))
+  "Haxe-specific header arguments.
+org-babel supports three of the platforms the haxe compiler can target.
+
+  `interp' runs the haxe compiler with the `--interp' option.
+  `neko' and `hashlink' compile to bytecode and run the
+  respective VMs.")
+
+(defvar org-babel-haxe-command "haxe"
+  "Name of the haxe command.")
+
+(defcustom org-babel-haxe-hline-to "null"
+  "Replace hlines in incoming tables with this when translating to haxe."
+  :group 'org-babel
+  :version "25.2"
+  :package-version '(Org . "9.3")
+  :type 'string)
+
+(defcustom org-babel-haxe-null-to 'hline
+  "Replace `null' in haxe tables with this before returning."
+  :group 'org-babel
+  :version "25.2"
+  :package-version '(Org . "9.3")
+  :type 'symbol)
+
+(defun org-babel-execute:haxe (body params)
+  "Execute a haxe source block with BODY code and PARAMS params."
+  (let* ((fullclassname (or (cdr (assq :classname params)) ; class and package
+(org-babel-haxe-find-classname body)
+"Main"))
+ (classname (if (seq-contains fullclassname ?.); just class name
+(file-name-extension fullclassname)
+  fullclassname))
+ (packagename (if (seq-contains fullclassname ?.)  ; just package name
+  (file-name-base fullclassname)
+""))
+ (packagedir (if (not (seq-empty-p packagename))   ; package name as a path
+ (replace-regexp-in-string "\\\." "/" packagename)))
+ (src-file (concat (replace-regexp-in-string "\\\." "/" fullclassname) ".hx"))
+ (cmdline (or (cdr (assq :cmdline params)) ""))
+ (target-name (cdr (assq :target params)))
+ (target (cond ((string= target-name "neko") "-neko main.n -cmd \"neko main.n\"")
+   ((string= target-name "hashlink") "-hl main.hl -cmd \"hl main.hl\"")
+   (t "--interp")))
+ (cmd (concat org-babel-haxe-command
+  " " cmdline " -main " fullclassname " " target))
+ (result-type (cdr (assq :result-ty

Re: org-babel :colnames yes

[ian martins]

Nick Dokos wrote:

> Would this work for you?
>
> #+BEGIN_SRC elisp :colnames yes
>   '((one two) hline (1 3) (1 6))
> #+END_SRC
>

Yes, that works. Thanks.

Re: org-babel :colnames yes

[ian martins]

I figured out that inserting `hline' works for some languages.  consistent
behavior with ":colnames yes" would be ideal but this solves my problem.

#+BEGIN_SRC elisp
  '((one two) hline (1 3) (1 6))
#+END_SRC

On Thu, May 28, 2020 at 7:48 AM ian martins  wrote:

> Hello, I'm trying to figure out how to tell org that the first row of a
> src block result is a table header.
>
> from readthedocs
> <https://org-babel.readthedocs.io/en/latest/header-args/#colnames> it
> looks like ":colnames yes" should do this, but I haven't been able to get
> it to work, and the code
> <https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-core.el#L1671>
> doesn't appear to want that to happen. maybe that is special handling for
> R <https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-R.el#L164>.
>
> #+BEGIN_SRC elisp :colnames yes
>   '((one two) (1 3) (1 6))
> #+END_SRC
>
> I'm expecting an hline in the output but do not find one.
>
> I know ":colnames '(one two)" works, but I don't know the header value
> until I've generated the table.
>
> -Ian
>

org-babel :colnames yes

[ian martins]

Hello, I'm trying to figure out how to tell org that the first row of a src
block result is a table header.

from readthedocs
 it looks
like ":colnames yes" should do this, but I haven't been able to get it to
work, and the code

doesn't appear to want that to happen. maybe that is special handling for R
.

#+BEGIN_SRC elisp :colnames yes
  '((one two) (1 3) (1 6))
#+END_SRC

I'm expecting an hline in the output but do not find one.

I know ":colnames '(one two)" works, but I don't know the header value
until I've generated the table.

-Ian

Re: Bug: org-map-entries infinite loop for org file with tags [9.2.6 (9.2.6-elpa @ /home/ian/.emacs.d/elpa/org-9.2.6/)]

[ian martins]

Thanks for looking into it. The problem was most likely an incompatibility
between emacs 24.5.1 and org 9.2.6. I upgraded emacs and it went away.

On Wed, Feb 5, 2020 at 2:13 AM Bastien  wrote:

> Hi Ian,
>
> > Running org-map-entries on an org file with tags results in an infinite
> > loop.
>
> FWIW, I cannot reproduce this.
>
> > Example function using org-map-entries:
> >
> > (defun org-map-entries-test ()
> >   (interactive)
> >   (org-map-entries '(lambda () (message "%s" (org-entry-properties
> > (point) 'standard
> >   (message "done"))
> >
> > Example org file:
> >
> > * one
> > * two
> > * three
> >  :noexport:
>
> The above exemple is not a valid org file, the tag should be on the
> same line than the headline... but perhaps that's just because your
> email was sent as HTML.
>
> Thanks,
>
> --
>  Bastien
>

[PATCH] org-timer.el: Allow org-timer-set-timer from non-Org buffers

[ian martins]

> There's a small typo in the docstring.  :)

So sorry. I reworded it enough times that I should have known it was bound
to be wrong.

Here is an update so Kyle won't have to clean it up later.
From f2271696889da6fded812b74c452571729e54384 Mon Sep 17 00:00:00 2001
From: ian 
Date: Sat, 16 Nov 2019 13:18:17 -0500
Subject: [PATCH] org-timer.el: Allow org-timer-set-timer from non-Org buffers

* org-timer.el (org-timer--get-timer-title): If the current buffer is
not an Org buffer, use the buffer name as the timer title.

Currently all of the `org-timer-' operations work from any buffer
except `org-timer-set-timer' which must be run from an Org buffer.
This is because `org-timer-set-timer' sets a timer name based on an
Org heading or filename.  By setting the timer title to the current
buffer name we can use `org-timer-set-timer' from any buffer and
preserve the timer naming convention of using the buffer name if there
isn't an Org header.

TINYCHANGE
---
 lisp/org-timer.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/org-timer.el b/lisp/org-timer.el
index 9674219..68fe966 100644
--- a/lisp/org-timer.el
+++ b/lisp/org-timer.el
@@ -466,7 +466,8 @@ time is up."
 		 (run-hooks 'org-timer-done-hook)
 
 (defun org-timer--get-timer-title ()
-  "Construct timer title from heading or file name of Org buffer."
+  "Construct timer title.
+Try to use an Org header, otherwise use the buffer name."
   (cond
((derived-mode-p 'org-agenda-mode)
 (let* ((marker (or (get-text-property (point) 'org-marker)
@@ -482,7 +483,7 @@ time is up."
((derived-mode-p 'org-mode)
 (or (ignore-errors (org-get-heading))
 	(buffer-name (buffer-base-buffer
-   (t (error "Not in an Org buffer"
+   (t (buffer-name (buffer-base-buffer)
 
 (provide 'org-timer)
 
-- 
2.7.4

[PATCH] org-timer.el: Allow org-timer-set-timer from non-Org buffers

[ian martins]

Hi. Tiny patch enclosed.
From d2af2e877147cc7be1f0c40455c9091f130c2159 Mon Sep 17 00:00:00 2001
From: ian 
Date: Sat, 16 Nov 2019 13:18:17 -0500
Subject: [PATCH] org-timer.el: Allow org-timer-set-timer from non-Org buffers

* org-timer.el (org-timer--get-timer-title): If the current buffer is
not an Org buffer, use the buffer name as the timer title.

Currently all of the `org-timer-' operations work from any buffer
except `org-timer-set-timer' which must be run from an Org buffer.
This is because `org-timer-set-timer' sets a timer name based on an
Org heading or filename.  By setting the timer title to the current
buffer name we can use `org-timer-set-timer' from any buffer and
preserve the timer naming convention of using the buffer name if there
isn't an Org header.

TINYCHANGE
---
 lisp/org-timer.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/org-timer.el b/lisp/org-timer.el
index 9674219..4367869 100644
--- a/lisp/org-timer.el
+++ b/lisp/org-timer.el
@@ -466,7 +466,8 @@ time is up."
 		 (run-hooks 'org-timer-done-hook)
 
 (defun org-timer--get-timer-title ()
-  "Construct timer title from heading or file name of Org buffer."
+  "Construct timer title.
+Try to us an Org header, otherwise use the buffer name."
   (cond
((derived-mode-p 'org-agenda-mode)
 (let* ((marker (or (get-text-property (point) 'org-marker)
@@ -482,7 +483,7 @@ time is up."
((derived-mode-p 'org-mode)
 (or (ignore-errors (org-get-heading))
 	(buffer-name (buffer-base-buffer
-   (t (error "Not in an Org buffer"
+   (t (buffer-name (buffer-base-buffer)
 
 (provide 'org-timer)
 
-- 
2.7.4

org-timer-set-timer from any buffer

[ian martins]

Is it intentional that org-timer start, stop, and pause-or-continue all
work from any buffer, but org-timer-set-timer only works from an org buffer?

Bug: org-map-entries infinite loop for org file with tags [9.2.6 (9.2.6-elpa @ /home/ian/.emacs.d/elpa/org-9.2.6/)]

[ian martins]

Running org-map-entries on an org file with tags results in an infinite
loop.

Example function using org-map-entries:

(defun scrum-test ()
  (interactive)
  (org-map-entries '(lambda () (message "%s" (org-entry-properties
(point) 'standard
  (message "done"))

Example org file:

* one
* two
* three
 :noexport:

expected result: visit each headline once then print "done"
actual result: visits headlines in an infinite loop and never prints "done"

It fails with: Org mode version 9.2.6 (9.2.6-elpa @
/home/ian/.emacs.d/elpa/org-9.2.6/)
It works with: Org-mode version 8.2.10 (release_8.2.10 @
/usr/share/emacs/24.5/lisp/org/)
It also works if the org file has no tags.


Emacs  : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2017-09-20 on lcy01-07, modified by Debian
Package: Org mode version 9.2.6 (9.2.6-elpa @
/home/ian/.emacs.d/elpa/org-9.2.6/)

current state:
==
(setq
 org-table-export-default-format "orgtbl-to-csv"
 org-hide-leading-stars 'hidestars
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-log-done t
 org-confirm-shell-link-function 'yes-or-no-p
 org-startup-folded 'content
 org-from-is-user-regexp "\\"
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append
local]
   5 "\n\n(fn)"]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local]
   5 "\n\n(fn)"]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees
  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-babel-tangle-lang-exts '(("python" . "py") ("java" . "java")
  ("emacs-lisp" . "el") ("elisp" . "el"))
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("id" :follow org-id-open)
   ("eww" :follow eww :store org-eww-store-link)
   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store
org-mhe-store-link)
   ("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
   ("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
   ("gnus" :follow org-gnus-open :store
org-gnus-store-link)
   ("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
   ("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
   ("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete org-bbdb-complete-link
:store org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link) ("file+sys")
   ("file+emacs") ("doi" :follow org--open-doi-link)
   ("elisp" :follow org--open-elisp-link)
   ("file" :complete org-file-complete-link)
   ("ftp" :follow
(lambda (path) (browse-url (concat "ftp:" path
   ("help" :follow org--open-help-link)
   ("http" :follow
(lambda (path) (browse-url (concat "http:" path
   ("https" :follow
(lambda (path) (browse-url (concat "https:" path
   ("mailto" :follow
(lambda (path) (browse-url (concat "mailto:; path)))
)
   ("news" :follow
(lambda (path) (browse-url (concat "news:; path
   ("shell" :follow org--open-shell-link))
 org-babel-load-languages '((java . t) (python . t) (emacs-lisp . t)
(calc . t) (org . t) (screen . t) (dot . t)
(plantuml . t) (gnuplot . t))
 

org-scrum

[ian martins]

Hello, I wrote some helper functions for generating a scrum board and
reports that is built on top of org-mode. The project is currently
emacs-scrum . I submitted it to melpa
recently and got the suggestion to name the package org-scrum since it's
based on org-mode. Is that fine?

-Ian

[O] Bug: org-map-entries infinite loop for org file with tags [9.2.6 (9.2.6-elpa @ /home/ian/.emacs.d/elpa/org-9.2.6/)]

[ian martins]

Running org-map-entries on an org file with tags results in an infinite
loop.

Example function using org-map-entries:

(defun org-map-entries-test ()
  (interactive)
  (org-map-entries '(lambda () (message "%s" (org-entry-properties
(point) 'standard
  (message "done"))

Example org file:

* one
* two
* three
 :noexport:

expected result: visit each headline once then print "done"
actual result: visits headlines in an infinite loop and never prints "done"

It fails with: Org mode version 9.2.6 (9.2.6-elpa @
/home/ian/.emacs.d/elpa/org-9.2.6/)
It works with: Org-mode version 8.2.10 (release_8.2.10 @
/usr/share/emacs/24.5/lisp/org/)
It also works if the org file has no tags.


Emacs  : GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2017-09-20 on lcy01-07, modified by Debian
Package: Org mode version 9.2.6 (9.2.6-elpa @
/home/ian/.emacs.d/elpa/org-9.2.6/)

current state:
==
(setq
 org-table-export-default-format "orgtbl-to-csv"
 org-hide-leading-stars 'hidestars
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-log-done t
 org-confirm-shell-link-function 'yes-or-no-p
 org-startup-folded 'content
 org-from-is-user-regexp "\\"
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
 org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-show-all append
local]
   5 "\n\n(fn)"]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local]
   5 "\n\n(fn)"]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-bibtex-headline-format-function #[257 "\300.\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees
  org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-babel-tangle-lang-exts '(("python" . "py") ("java" . "java")
  ("emacs-lisp" . "el") ("elisp" . "el"))
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-link-parameters '(("id" :follow org-id-open)
   ("eww" :follow eww :store org-eww-store-link)
   ("rmail" :follow org-rmail-open :store
org-rmail-store-link)
   ("mhe" :follow org-mhe-open :store
org-mhe-store-link)
   ("irc" :follow org-irc-visit :store
org-irc-store-link :export org-irc-export)
   ("info" :follow org-info-open :export
org-info-export :store org-info-store-link)
   ("gnus" :follow org-gnus-open :store
org-gnus-store-link)
   ("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
   ("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
   ("bbdb" :follow org-bbdb-open :export
org-bbdb-export :complete org-bbdb-complete-link
:store org-bbdb-store-link)
   ("w3m" :store org-w3m-store-link) ("file+sys")
   ("file+emacs") ("doi" :follow org--open-doi-link)
   ("elisp" :follow org--open-elisp-link)
   ("file" :complete org-file-complete-link)
   ("ftp" :follow
(lambda (path) (browse-url (concat "ftp:" path
   ("help" :follow org--open-help-link)
   ("http" :follow
(lambda (path) (browse-url (concat "http:" path
   ("https" :follow
(lambda (path) (browse-url (concat "https:" path
   ("mailto" :follow
(lambda (path) (browse-url (concat "mailto:; path)))
)
   ("news" :follow
(lambda (path) (browse-url (concat "news:; path
   ("shell" :follow org--open-shell-link))
 org-babel-load-languages '((java . t) (python . t) (emacs-lisp . t)
(calc . t) (org . t) (screen . t) (dot . t)
(plantuml . t) (gnuplot . t))