Org-Mode Evaluation of code disabled

[atrifex]

I am trying to run code as a part of org-mode's code blocks. However, it keeps saying that evaluation of code-blocks is disabled. I am not sure where to go to turn this option on. Please let me know. Thank you in advance.

[TheBB]

http://orgmode.org/manual/index.html

[atrifex]

I actually looked through this page.

I am currently doing the following in my user-config()

  (with-eval-after-load 'org
    (require 'ob-python)
    (org-babel-do-load-languages
     'org-babel-load-languages
     '((C . t)
       (python . t)))
  )

However, this doesn't seem to change anything.

[LemmingAvalanche]

I was able to get Python to work.

In my dotspacemacs/user-init:

(require 'ob-python)
(org-babel-do-load-languages
  'org-babel-load-languages
  '((python . t)))

So I didn’t use the with-eval-after-load bit.

I also included the Python layer in dotspacemacs/layers.

Then I executed org-babel-execute-src-block while point was inside the source block below:

#+BEGIN_SRC python
import time
print("Hello, today's date is %s" % time.ctime())
print('Two plus two is')
return 2 + 2
#+END_SRC

#+RESULTS:
: 4

I get prompted about whether I want to execute the code each time I execute that function.

⁂

Could you try the above? Then try with C if that works.

[atrifex]

It did help with that. However, for some reason the bullets just appear as , *, ***. This is not a big deal however cuz i am just manually able to turn them on with little to no effort. Thank.

[LemmingAvalanche]

@TheBB it seems that this can be closed.

[agzam]

Let's re-open this issue, something definitely not right, in org 9.0 you have to load explicitly for every language you want to use? Every language I'm trying not working. lua (which supposed to be added in 9.0), javascript, bash, etc.

and ob-http (which is part of restclient layer) does not work at all - babel complains 'no such language mode: http-mode

[bmag]

@agzam it seems the issue has been resolved for @Atrifex so I closed it. I don't use org-babel and I'm not aware of the differences with Org 9.0, can you explain the bug using the usual template please?

[agzam]

@TheBB it was kinda expected - things to break due to org-mode 9.0. Maybe we need a separate issue or maybe each one should be treated individually - it's up to you guys, but there are couple of things that appear to be broken at the moment (prob. there is more, but that's what I can see):

• at Emacs startup, warning:

  Error (use-package): org post-:config hook: Unknown keyword: :export-block

• eval of org-babel languages doesn't work out of the box anymore, except for emacs-lisp, so if in org-mode you make something like:

  #+BEGIN_SRC shell
  ls
  #+END_SRC

and then C-c C-c to evaluate that piece, it would not do anything so EVERY single language (except emacs-lisp) now has to be explicitly loaded, e.g.:

(org-babel-do-load-languages
 'org-babel-load-languages
 '((shell . t)
   (js . t)
   (clojure . t) ... etc, etc.)

So maybe that should be handled by org-layer?

[nanounanue]

I have the same problem:

My version of org-mode is

Org mode version 9.0 (9.0-elpa @ /home/nanounanue/.emacs.d/elpa/org-20161102/)

the Emacs version is

GNU Emacs 26.0.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.20.8) of 2016-10-15

The relevant part of my personal emacs init file is:

(require 'ob-python)
(require 'ob-clojure)
(require 'ob-perl)
(require 'ob-dot)
(require 'ob-R)
(require 'ob-gnuplot)
(require 'ob-lisp)
(require 'ob-org)
(require 'ob-screen)
(require 'ob-calc)
(require 'ob-js)
(require 'ob-latex)
(require 'ob-plantuml)
(require 'ob-sh)
(require 'ob-ditaa)
(require 'ob-awk)
(require 'ob-octave)
(require 'ob-sed)
(require 'ob-sql)
(require 'ob-sqlite)

(org-babel-do-load-languages
 'org-babel-load-languages
 '( (perl . t)
    (dot . t)
    (R . t)
    (gnuplot . t)
    (clojure . t)
;;    (graphviz . t)
    (lisp . t)
;;    (stan . t)
    (org . t)
    (screen . t)
    (calc . t)
    (js . t)
    (latex . t)
    (plantuml . t)
    (ruby . t)
    (sh . t)
    (python . t)
    (emacs-lisp . t)
    (ditaa . t)
    (awk . t)
    (octave . t)
    (sed . t)
    (sql . t)
    (sqlite . t)
    ))

When I try to execute any block, even this from the documetation:

#+BEGIN_SRC emacs-lisp
(defun org-xor (a b)
"Exclusive or."
(if a (not b) b))
#+END_SRC

I got

Evaluation of this emacs-lisp code-blockis disabled.

The same happens with python, R, etc

Any ideas?

[madhat2r]

I have same exact issue as @nanounanue

[SimonAB]

Same problem here using ipython code blocks, and not using Spacemacs... This bug seems to have been introduced to org mode after 2016-10-31.

[seldomworks]

Deleting *.elc files for org mode was the only thing that fixed the issue for me. http://emacs.stackexchange.com/questions/28441/org-mode-9-unable-to-eval-code-blocks

[SimonAB]

@seldomworks I can confirm this worked for me too. Thanks!

[madhat2r]

This worked for me also, but in addition I had to recompile org-plus-contrib.

Thanks @seldomworks!

[cpaulik]

This might be related to the fact that a package update often installs org and org-plus-contrib in some order and the bytecode is then compiled with the wrong version. There might be a problem during the dependency resolution there.

[nickanderson]

Purging ~/.emacs.d/elpa/org-20161102/*.elcworked for me as well.

[mathpunk]

Purging ~/.emacs.d/elpa/org-20161102 did not work for me. Removed that entire dir, restarted emacs, same error.

(with-eval-after-load 'org
(setq-default dotspacemacs-configuration-layers
              '((org :variables org-enable-github-support t)))
(setq org-confirm-babel-evaluate nil
      org-src-fontify-natively t
      org-src-tab-acts-natively t)

(org-babel-do-load-languages
 'org-babel-load-languages
 '((http       . t)
   (sh         . t)
   (js         . t)
   (emacs-lisp . t)
   (clojure    . t)
   (python     . t)
   (dot        . t)
   )))

I also tried putting in a (require 'ob-sh) to see if that had an effect, but no.

[nickanderson]

Did you try just removing the elc files?

[mathpunk]

@nickanderson That was the first thing that I tried. But I assumed that just trying to run the thing would get those files recompiled, and now I'm wondering if I need to take more action to get org reinstalled --- it is listed as a package in my .spacemacs, but the org directory has not reappeared in ~/.emacs.d/elpa.

[nickanderson]

@mathpunk I had previously tried without success to delete the org directory in ~/.emacs.d/elpa. Restarting emacs would cause the package to he re-downloaded but my issue with SRC blocks persisted until I only removed the elc files and then restarted emacs.

[dubnde]

I still see this issue as well

[Rand01ph]

reinstall org layer maybe reslove this problem

[dubnde]

@Rand01ph works if I delete the org-plus-contrib package in elpa folder so it reinstalls on next start up.

Note: It did not work when I wiped all org- packages or wiped the whole elpa folder. So it does seem the org-plus-contrib package must be the last package to install to mitigate the issue.

rm -rf elpa/org-plus-contrib-20161118/

[dubnde]

blind me! It only works for a single session. If I restart emacs, stops working. Got to delete org-plus-contrib again.

[mathpunk]

I tried @dubnde's workaround. I closed spacemacs, deleted elpa/org-plus-contrib, and restarted. An org-mode src block of type python or restclient work fine and give the expected results. But a src block of type sh yields

Symbol's function definition is void: org-babel-get-header

If I restart the computer, both the good and bad behavior persist.

[nickanderson]

Try switching the src block to shell instead of sh. Had to do that throughout my org files.

[mathpunk]

@nickanderson: Funny, I had tried labeling the src block as shell and it complained that it knew of no such thing. But after your comment I changed this in my .spacemacs

(org-babel-do-load-languages
 'org-babel-load-languages
 '((shell         . t)  ;; was: (sh  . t)
  ...))

and now src blocks labeled sh work as expected. Thanks!

[dubnde]

Just not working for me. Seeing lots of warnings as follows

Warning (bytecomp): the function ‘org-babel--get-vars’ is not known to be defined.
Warning (bytecomp): reference to free variable ‘org-babel-safe-header-args’
Warning (bytecomp): Unused lexical variable ‘raw’
Warning (bytecomp): the following functions are not known to be defined:
    org-babel-header-args-safe-fn, org-babel-graphical-output-file,
    org-babel--get-vars
Warning (bytecomp): the function ‘org-babel--get-vars’ is not known to be defined. [5 times]
Warning (bytecomp): function org-babel-check-confirm-evaluate used to take 1+ arguments, now takes 1
Warning (bytecomp): macro ‘org-babel-check-confirm-evaluate’ being redefined as a function
Warning (bytecomp): Unused lexical variable ‘block-name’
Warning (bytecomp): Unused lexical variable ‘code-block’
Warning (bytecomp): Unused lexical variable ‘query’
Warning (bytecomp): Unused lexical variable ‘noeval’
Warning (bytecomp): Unused lexical variable ‘block-name’
Warning (bytecomp): Unused lexical variable ‘code-block’
Warning (bytecomp): Unused lexical variable ‘query’
Warning (bytecomp): Unused lexical variable ‘noeval’
Warning (bytecomp): function org-babel-set-current-result-hash used to take 1 argument, now takes 2
Warning (bytecomp): function org-babel-find-named-result used to take 1-2 arguments, now takes 1
Warning (bytecomp): function org-babel-where-is-src-block-result used to take 0-4 arguments, now takes 0-3
Warning (bytecomp): function org-babel-insert-result used to take 1-6 arguments, now takes 1-5
Warning (bytecomp): the function ‘org-unbracket-string’ is not known to be defined.
Warning (bytecomp): the function ‘org-babel--get-vars’ is not known to be defined.
Warning (bytecomp): the following functions are not known to be defined: org-babel--get-vars,
    org-babel-make-language-alias
Warning (bytecomp): function org-babel-exp-src-block used to take 0+ arguments, now takes 0
Warning (bytecomp): reference to free variable ‘org-babel-exp-reference-buffer’
Warning (bytecomp): org-babel-get-src-block-info called with 2 arguments, but accepts only 0-1
Warning (bytecomp): org-babel-exp-code called with 2 arguments, but accepts only 1 [2 times]
Warning (bytecomp): function org-babel-exp-code used to take 1 argument, now takes 2
Warning (bytecomp): reference to free variable ‘org-babel-exp-reference-buffer’ [2 times]
Warning (bytecomp): the function ‘org-babel-remove-inline-result’ is not known to be defined.
Warning (bytecomp): the function ‘org-babel--get-vars’ is not known to be defined. [3 times]
Warning (bytecomp): Unused lexical variable ‘raw’
Warning (bytecomp): the following functions are not known to be defined: org-babel-strip-quotes,

[duianto]

I just started learning about org-mode and ran into this issue yesterday.

#+BEGIN_SRC emacs-lisp
(+ 2 8)
#+END_SRC

C-c C-c

Evaluation of this emacs-lisp code block is disabled.

I tried removing and reinstalling the org package but that didn't help, then i found this comment: http://emacs.stackexchange.com/questions/28441/org-mode-9-unable-to-eval-code-blocks/28448#28448 it mentions deleting the .elc files, and that works. And it also works, if after deleting the .elc files, the org package directory is byte recompiled.

C-u 0 M-x byte-recompile-directory RET ~/emacs.d/elpa/org-20161118

#+BEGIN_SRC emacs-lisp
(+ 2 8)
#+END_SRC

C-c C-c

Evaluate this emacs-lisp code block on your system? (yes or no) yes

#+RESULTS:
: 10

It keeps working after restarting emacs.

Possible reason

Could it be that the .elc files in the melpa org package were compiled with an older org version?

PS. Or does the melpa packages only contain the .el files, and they are compiled after they are downloaded? Then maybe the issues occurs when they are compiled.

System Info

Windows 10 Version 1607 (OS Build 14393.447) GNU Emacs 25.1.1 (i686-w64-mingw32) of 2016-09-17 org mode version 9.0.1 (org-20161118) C-h v org-babel-load-languages

Its value is ((emacs-lisp . t))

[dubnde]

@duianto than you. that fixed it.

Did about 10 emacs restart and still works.

I am wondering why it does not work when I wipe out the whole elpa folder? As you say, could it be that the .elc files in the spacemacs org package (version 9.0.1) folder are earlier compiled with the built in version 8.2.10 of my emacs installation.

[torgeir]

+1 on @duianto's solution: deleting the org-mode elc-files did the trick for me.

$ cd ~/.emacs.d/elpa 
$ rm org-plus-contrib-20161102/*.elc

(I'm not in spacemacs and hit this with org-plus-contrib too)

[duerrp]

For me, org-reload with C-u C-u fixes the problem, but only for the current emacs instance, maybe that is a clue...

[LemmingAvalanche]

29 days ago I wrote:

I was able to get Python to work.

This was probably because I hadn’t upgraded to Org version 9.0 at the time. Now that I have upgraded I’m having the same problem as others in this thread, i.e., that evaluation is “disabled”.

I ran this to get rid of Org-stuff in Elpa:

cd .emacs.d/elpa
trash org*

Then I was allowed to evaluate source blocks, after having said “yes” to the prompt. But this only works after having restarted Spacemacs once; it doesn’t work when I restart Spacemacs a second time. Then I have to delete the Org-stuff in Elpa in order for things to work again.

But while Org-babel evaluation was ostensibly working, I got this error when I tried to evaluate a (shell) code block:

org-babel-variable-assignments:shell: Symbol's function definition is void: org-babel--get-vars

The same happened when I tried to evaluate this Python block (same as in my first post in this thread, 29 days ago):

import time
print("Hello, today's date is %s" % time.ctime())
print('Two plus two is')
return 2 + 2

Searching through this thread for the string org-babel--get-vars, I see that it came up in this comment.

[dingmingxin]

@duianto +1 thank you, that fixed it. Still working after restarting emacs

[yssource]

+1 @torgeir Thank you. rm org-plus-contrib-20161102/*.elc working for me. Not only for the current emacs instance, Still working after restarting emacs

[mathpunk]

I'm back to being unable to evaluate source blocks, and looking in my elpa directory, I don't even have an org-plus-contrib-***** directory to try this "delete the compiled files" workaround.

[oneyb]

I report the same problem with the following purge sufficing as a workaround.

find ~/.emacs.d/elpa/org -name "elc" -delete

System Info :computer:

• OS: gnu/linux
• Emacs: 24.5.1
• Spacemacs: 0.200.5
• Spacemacs branch: master (rev. 664ba6a)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

  (html vimscript auto-completion better-defaults emacs-lisp git lua
    (markdown :eval-after-load
              (auto-fill-mode 1)
              (spacemacs/toggle-auto-completion))
    pandoc
    (org :eval-after-load
         (auto-fill-mode 1)
         (spacemacs/toggle-auto-completion))
    (latex :variables latex-enable-auto-fill t :eval-after-load
           (auto-fill-mode 1)
           (spacemacs/toggle-auto-completion))
    shell-scripts syntax-checking
    (ess :variables ess-enable-smart-equals t)
    python csv)

[xificurC]

Quite interesting that rm -rf ~/.emacs.d/elpa and restart of spacemacs didn't solve this, but then a find ~/.emacs.d/elpa/org* -name "*elc" -delete solved it. It would seem the byte compilation messes something up?

[oneyb]

I think it's all related. see https://github.com/syl20bnr/spacemacs/issues/4618 specifically: https://github.com/syl20bnr/spacemacs/issues/4618#issuecomment-175789521

I guess the broad removal of all byte-compiled files is overkill, but doesn't break anything (for me, yet).

My experience is that org-mode is a moving target and it happens to often that my org files won't compile/export to anything. I am annoyed but somehow still stick with org. It may be advisable for spacemacs to be specific about which version it uses, to keep things from breaking. Any further thoughts? How could I be specific about which version of org I install?

[RockyRoad29]

After trying unsuccessfully to debug the faulty #'org-babel-confirm-evaluate I decided to compare myself the "old" code, i.e. /usr/share/emacs/25.1/lisp/org/ob-core.el.gz and the new : ~/.emacs.d/elpa/org-plus-contrib-20170210/ob*.el: I found these interesting:

So the key point is that the definitions used to be inline functions, which are hard to debug and to get rid of.

\o/ :white_check_mark: After recompiling specifically elpa/org-plus-contrib-20170210/ob-core.el , Org Babel evaluation works !

I still wonder why recompile-elpa didn't do the job.

[aang7]

@RockyRoad29 Yiep! It works for me, thanks:) PD: When I Update org-mode something breaks :face_with_head_bandage:

[Atraii]

I would like to add that after deleting the *.elc files and recompiling, the python and emacs-lisp babel packages work for me, but C and C++ do not still.

I am getting No org-babel-execute function for C++!

Any solution for this?

[krux02]

I just wanted to comment. I tried several things here. I don't know what is the right thing to do and what is the wrong thing to do. I have this problem, and I thing this bug should get highest priority.

[aang7]

@ Krux02 Yep! It's so stressful that something breaks down when we update emacs packages, primordially org.

[krux02]

I just realized that this is the spacemacs issue tracker. I did not know that when I wrote that comment. I don't use spacemacs, and still I had this problem. I don't know if it helps to know that this problem is not just a spacemacs thing.

[agzam]

@krux02 then maybe you should switch to Spacemacs. Some users don't have that problem ;)

[nickanderson]

I had this again after wiping my elpa subdirectory. This time purging ~/.emacs.d/elpa/org-plus-contrib-* and restarting emacs seemed to do the trick as noted in https://github.com/syl20bnr/spacemacs/issues/7641#issuecomment-261770838 I hadn't made it down to https://github.com/syl20bnr/spacemacs/issues/7641#issuecomment-281788811 which is probably more specific.

[frapples]

I suggest that after upgrading org-mode, recompile the .elc file:

:spacemacs/recompile-elpa

[mathpunk]

@frapples I am very happy that you've taught me this command exists; I've tried to force recompiling using deletions but this is better.

[localredhead]

@frapples that simple command did the trick for me. thanks!