Aloha all, I pushed a new file, ob-doc-org.org, to Worg earlier today, but the link in https://orgmode.org/worg/org-contrib/babel/languages/index.html gives a 404 error. I usually see this when the Org file has a bad link that causes export to fail, but AFAICT ob-doc-org.org doesn't have this affliction--it exports locally. I've likely made some other error, but I don't have clue what it might be. I don't know how to debug this. Can someone help, please? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
On 08/11/2021 05:46, Thomas S. Dye wrote: > > I pushed a new file, ob-doc-org.org, to Worg earlier today, but the link > in https://orgmode.org/worg/org-contrib/babel/languages/index.html gives > a 404 error. I usually see this when the Org file has a bad link that > causes export to fail, but AFAICT ob-doc-org.org doesn't have this > affliction--it exports locally. > > I've likely made some other error, but I don't have clue what it might be. > > I don't know how to debug this. Can someone help, please? https://builds.sr.ht/~bzg/job/623225 [exporting] org-contrib/babel/languages/ob-doc-org.org No org-babel-execute function for org! However I do not see explicit load/require for particular language in sibling files. I expected something like #+begin_src emacs-lisp :exports none (require 'ob-org) #+end_src
Aloha Max, Max Nikulin <manikulin@gmail.com> writes: > On 08/11/2021 05:46, Thomas S. Dye wrote: >> I pushed a new file, ob-doc-org.org, to Worg earlier today, but >> the link >> in >> https://orgmode.org/worg/org-contrib/babel/languages/index.html >> gives a 404 >> error. I usually see this when the Org file has a bad link >> that causes export >> to fail, but AFAICT ob-doc-org.org doesn't have this >> affliction--it exports >> locally. >> I've likely made some other error, but I don't have clue what >> it might be. >> I don't know how to debug this. Can someone help, please? > > https://builds.sr.ht/~bzg/job/623225 > > [exporting] org-contrib/babel/languages/ob-doc-org.org > No org-babel-execute function for org! > > However I do not see explicit load/require for particular > language in sibling > files. I expected something like > > #+begin_src emacs-lisp :exports none > (require 'ob-org) > #+end_src Thanks for looking into this. Is the problem something I can fix in ob-doc-org.org? Or, does it have to do with the configuration at sr.ht? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
On 11/11/2021 04:24, Thomas S. Dye wrote: > Max Nikulin writes: >> On 08/11/2021 05:46, Thomas S. Dye wrote: >>> to fail, but AFAICT ob-doc-org.org doesn't have this affliction--it >>> exports locally. Have you tried to export it from "emacs -Q -L /path/to/org-mode/lisp"? I think, you just have "org" in customized "org-babel-load-languages". >>> I've likely made some other error, but I don't have clue what it >>> might be. >>> I don't know how to debug this. Can someone help, please? >> >> https://builds.sr.ht/~bzg/job/623225 >> >> [exporting] org-contrib/babel/languages/ob-doc-org.org >> No org-babel-execute function for org! >> >> However I do not see explicit load/require for particular language in >> sibling >> files. I expected something like >> >> #+begin_src emacs-lisp :exports none >> (require 'ob-org) >> #+end_src > > Thanks for looking into this. > > Is the problem something I can fix in ob-doc-org.org? Or, does it have > to do with the configuration at sr.ht? All settings are in .build.yaml and publish.sh (lisp) file. Sorry, I have missed the following code in your file #+begin_src emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src I am unsure whether it should work in this form or it worked earlier, but on main branch it is not executed during export. If I change first line to the following, the block is executed during export: #+begin_src emacs-lisp :results value none :exports results My minimal example: Test #+begin_src emacs-lisp :results value none :exports results (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src #+name: org-hello #+begin_src org :var hello="World" Hello, $hello! #+end_src #+begin_src elisp :var x=org-hello[](hello="Org") :exports both (print x) #+end_src
Aloha Max, Max Nikulin <manikulin@gmail.com> writes: > On 11/11/2021 04:24, Thomas S. Dye wrote: >> Max Nikulin writes: >>> On 08/11/2021 05:46, Thomas S. Dye wrote: >>>> to fail, but AFAICT ob-doc-org.org doesn't have this >>>> affliction--it exports >>>> locally. > > Have you tried to export it from "emacs -Q -L > /path/to/org-mode/lisp"? > I think, you just have "org" in customized > "org-babel-load-languages". > >>>> I've likely made some other error, but I don't have clue what >>>> it might be. >>>> I don't know how to debug this. Can someone help, please? >>> >>> https://builds.sr.ht/~bzg/job/623225 >>> >>> [exporting] org-contrib/babel/languages/ob-doc-org.org >>> No org-babel-execute function for org! >>> >>> However I do not see explicit load/require for particular >>> language in sibling >>> files. I expected something like >>> >>> #+begin_src emacs-lisp :exports none >>> (require 'ob-org) >>> #+end_src >> Thanks for looking into this. >> Is the problem something I can fix in ob-doc-org.org? Or, does >> it have >> to do with the configuration at sr.ht? > > All settings are in .build.yaml and publish.sh (lisp) file. > > Sorry, I have missed the following code in your file > > #+begin_src emacs-lisp > (org-babel-do-load-languages > 'org-babel-load-languages > '((org . t))) > #+end_src > > I am unsure whether it should work in this form or it worked > earlier, but on > main branch it is not executed during export. If I change first > line to the > following, the block is executed during export: > > #+begin_src emacs-lisp :results value none :exports results > > My minimal example: > > Test > > #+begin_src emacs-lisp :results value none :exports results > (org-babel-do-load-languages > 'org-babel-load-languages > '((org . t))) > #+end_src > > #+name: org-hello > #+begin_src org :var hello="World" > Hello, $hello! > #+end_src > > #+begin_src elisp :var x=org-hello[](hello="Org") :exports both > (print x) > #+end_src Thanks! The original problem is likely due to the default header arguments in ob-org.el, which are unusual. If I export both, then all is well. #+begin_src emacs-lisp :results value none :exports both (org-babel-do-load-languages 'org-babel-load-languages '((org . t))) #+end_src All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
On 12/11/2021 00:24, Thomas S. Dye wrote: > > The original problem is likely due to the default header arguments in > ob-org.el, which are unusual. It is great that the problem is solved. I do not think however that something inside ob-org.el may affect processing of a file before this package is loaded. > If I export both, then all is well. > > #+begin_src emacs-lisp :results value none :exports both > (org-babel-do-load-languages > 'org-babel-load-languages > '((org . t))) > #+end_src I feel that I have missed something. I do not see the purpose to include this source block in user docs. I expect that for accidental usage it is more convenient to type (require 'ob-org), while as a permanent settings it is possible to do customize-variable org-babel-load-languages or to use `add-to-list'.
Aloha Max, Max Nikulin <manikulin@gmail.com> writes: > On 12/11/2021 00:24, Thomas S. Dye wrote: >> The original problem is likely due to the default header >> arguments in >> ob-org.el, which are unusual. > > It is great that the problem is solved. I do not think however > that something > inside ob-org.el may affect processing of a file before this > package is loaded. > >> If I export both, then all is well. >> #+begin_src emacs-lisp :results value none :exports both >> (org-babel-do-load-languages >> 'org-babel-load-languages >> '((org . t))) >> #+end_src > > I feel that I have missed something. I do not see the purpose to > include this > source block in user docs. I expect that for accidental usage it > is more > convenient to type (require 'ob-org), while as a permanent > settings it is > possible to do customize-variable org-babel-load-languages or to > use > `add-to-list'. The source block is included to show the user how to modify their .emacs. I was surprised that changing its :results header argument had an effect on export. Do you have an explanation why the header argument makes this difference on Worg? All the best, Tom -- Thomas S. Dye https://tsdye.online/tsdye
On 12/11/2021 23:55, Thomas S. Dye wrote: > Max Nikulin writes: > >> On 12/11/2021 00:24, Thomas S. Dye wrote: >>> The original problem is likely due to the default header arguments in >>> ob-org.el, which are unusual. >> >> It is great that the problem is solved. I do not think however that >> something >> inside ob-org.el may affect processing of a file before this package >> is loaded. >> >>> If I export both, then all is well. >>> #+begin_src emacs-lisp :results value none :exports both >>> (org-babel-do-load-languages >>> 'org-babel-load-languages >>> '((org . t))) >>> #+end_src >> >> I feel that I have missed something. I do not see the purpose to >> include this >> source block in user docs. I expect that for accidental usage it is more >> convenient to type (require 'ob-org), while as a permanent settings it is >> possible to do customize-variable org-babel-load-languages or to use >> `add-to-list'. > > The source block is included to show the user how to modify their .emacs. My ~/.emacs.d/init.el has (among other variables) (custom-set-variables '(org-babel-load-languages (quote ((emacs-lisp . t) (C . t) (python . t)))) ;; ... ) I consider it better since it does not force immediate loading of Org if emacs is launched for a file of different type. Before sending the previous message I forgot to check Org manual. It recommends `org-babel-do-load-language' and it looks more prominent than customizing of the variable, however a more concise example is given a bit below (require 'ob-closure) Additional feature of `org-babel-do-load-language' is that the function can "unload" some languages, however it is not the case for initialization. That is why I disputed recommending more complicated example with `org-babel-do-load-language'. It is matter of taste however even if current example has no less obvious advantages. > I was surprised that changing its :results header argument had an effect > on export. > > Do you have an explanation why the header argument makes this difference > on Worg? Worg build procedure is more close to defaults. Earlier I wrote that the issue can be reproduced locally using "emacs -Q". Actually it is reasonable that without explicit request, source blocks are not executed during export. `org-babel-default-header-args' has (:exports . "code"), so it is necessary to override default value to execute the source block loading ob-org. I was confused that build log contains a message related to evaluating of some code ob-doc-sql.org without explicit overriding of :exports. Likely it is caused by noweb option.