When the `emacs' command is used, then everything works as expected, and
the following

  #+results:
  : number 3

is inserted into the org-mode buffer, however when `emcasclient' is used
the call hangs forever.

At first this was puzzling, but it makes perfect sense, when org-babel
executes a source block, it does so in a synchronous blocking manner,
meaning that all of Emacs waits until the command returns before doing
anything, emacs "blocks" on the external call.  When the external
command wants to talk to Emacs, the external command waits on Emacs,
which is itself waiting on the external command -- and everyone waits
forever.

The only solutions here are the one you've found (which I'm honestly
surprised even works), for org-babel to implement non-blocking calls to
external processes (which may happen in the future, but not the
immediate future), or for Emacs to become multi-threaded (also only in
some possible non-immediate futures).

Thanks for pointing out this issue.  Please let me know if any of the
above doesn't make sense.

Best -- Eric

Erik Iverson <eriki@ccbr.umn.edu> writes:

> Hello,
>
> In the spirit of the examples of writing your .emacs file in orgmode,
> I wrote my .Rprofile (R's startup file) in orgmode.  I do have one
> issue where I have no idea what is going wrong, and would appreciate
> any information!
>
> Basic setup, GNU Emacs 23.1, latest git org-mode, running on Linux.  I
> start emacs with emacs --daemon on startup, and always just use
> emacsclient to do everything.  So for my org-mode .Rprofile,
>
> 1) I create a ~/.Rprofile.org file that uses org-mode syntax and
> includes all R code in R source blocks that will be tangled into a
> .Rprofile.R file.
>
> 2) In my actual .Rprofile, I have the following, which actually works.
> The basic idea was taken from
> http://orgmode.org/worg/org-contrib/babel/reference.php#sec-6 .  I
> simply want to tangle the .Rprofile.org file from (1) above into
> .Rprofile.R and source it. I know the lisp isn't as simple as it could
> be, since I adapted it from the more complex setup referenced, but
> this actually works for me.
>
> #BEGIN .Rprofile
> invisible(system("emacsclient -t --eval \"(progn
> (add-to-list 'load-path (expand-file-name \\\"~/lisp/org-mode/lisp/\\\"))
> (add-to-list 'load-path (expand-file-name \\\"~/lisp/org-mode/contrib/lisp/\\\"))
> (require 'org)(require 'org-exp)(require 'org-babel)
> (mapc (lambda (file)
>        (find-file (expand-file-name file \\\"/home/erik\\\"))
>        (org-babel-tangle)) '(\\\".Rprofile.org\\\")))\"", intern =
> TRUE, ignore.stderr = TRUE))
>
> source("~/.Rprofile.R")
> #END .Rprofile
>
> Then I do 'M-x R' in emacs, and R tangles the org-mode file, sources
> the result, and everything works.  This even works without the '-t'
> option given above to emacsclient.
>
> The problem is when I try to C-c C-c on an R source block in an
> org-mode file. My issue is, that *without* the '-t' option to
> emacsclient, (-t says it "opens a new emacs frame on the current
> terminal"), org-babel-execute-src-block hangs when I press C-c C-c in
> an R code block using the above setup.  It definitely relates to the
> emacsclient call in my .Rprofile,  because I can simply comment that
> system call out of my .Rprofile and all is well.  If I use :session,
> everything is fine.
>
> The best lead I have is that if I change org-babel-R-evaluate in the
> following way, my setup also works without the -t option:
>
> Give the R call in the following line
>
> (point-min) (point-max) "R --no-save" nil 'replace (current-buffer)))
>
> the --vanilla option.  Obviously this just doesn't run my problematic
> .Rprofile, but the point is that this is the exact location in the
> chain of calls where it's getting 'stuck'.  Emacs just hangs with the
> busy' mouse cursor until I C-g.
>
> If I watch the system process list, the R process does get started,
> and a new (2nd) instance of emacsclient is also started, but it
> doesn't return.
>
> Like I said, I have 'fixed' this with -t, but I really want to know
> why it wasn't working in the first place, and if this is really a fix.
> Notice how I have to also ignore.stderr = TRUE in my 'system' R call,
> because if I don't, all my org-babel output contains
>
> #+results:
> : emacsclient: could not get terminal name
> ...further output...
>
> if my source block has :results output as opposed to :results value.
>
> I just don't get why my setup works with M-x R but not with
> org-babel-execute-src-block, there is some interaction between those
> two and I can't see what it is.
>
> Sorry for the long post, I hope my question makes sense!
>
> Best Regards,
> Erik Iverson
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode