* "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` @ 2015-08-20 9:38 JI, Xiang 2015-08-20 9:44 ` JI, Xiang 0 siblings, 1 reply; 14+ messages in thread From: JI, Xiang @ 2015-08-20 9:38 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 663 bytes --] I’m trying to export all my agenda files into an ics file via org-icalendar-combine-agenda-files. However, the export process stops halfway through. The following are shown in Messages: org-babel-exp process emacs-lisp at line 72... org-babel-exp process emacs-lisp at line 208... user-error: No language for src block: (unnamed) which is weird because I already set org-calendar-include-body to nil. I don’t think a code block in the middle of a org file should impact iCalendar export. The code block begins with #BEGIN_SRC emacs-lisp and is highlighted correctly. I’m not sure why it says “no language for src block”. Regards, JI, Xiang [-- Attachment #2: Type: text/html, Size: 3681 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-20 9:38 "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` JI, Xiang @ 2015-08-20 9:44 ` JI, Xiang 2015-08-21 11:50 ` Nicolas Goaziou 0 siblings, 1 reply; 14+ messages in thread From: JI, Xiang @ 2015-08-20 9:44 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1053 bytes --] Well actually I think the error shows because of another block below the emacs-lisp blocks. In this header I just wrote #+BEGIN_SRC without any language name. Is it actually wrong and maybe I should have written #+BEGIN_EXAMPLE instead? Though I’d still say it probably shouldn’t have failed the export?… On 20. August 2015 at 17:38:36, JI, Xiang (hi@xiangji.me) wrote: I’m trying to export all my agenda files into an ics file via org-icalendar-combine-agenda-files. However, the export process stops halfway through. The following are shown in Messages: org-babel-exp process emacs-lisp at line 72... org-babel-exp process emacs-lisp at line 208... user-error: No language for src block: (unnamed) which is weird because I already set org-calendar-include-body to nil. I don’t think a code block in the middle of a org file should impact iCalendar export. The code block begins with #BEGIN_SRC emacs-lisp and is highlighted correctly. I’m not sure why it says “no language for src block”. Regards, JI, Xiang [-- Attachment #2: Type: text/html, Size: 4731 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-20 9:44 ` JI, Xiang @ 2015-08-21 11:50 ` Nicolas Goaziou 2015-08-21 13:46 ` Ista Zahn 0 siblings, 1 reply; 14+ messages in thread From: Nicolas Goaziou @ 2015-08-21 11:50 UTC (permalink / raw) To: JI, Xiang; +Cc: emacs-orgmode Hello, "JI, Xiang" <hi@xiangji.me> writes: > Well actually I think the error shows because of another block below > the emacs-lisp blocks. In this header I just wrote #+BEGIN_SRC without > any language name. Is it actually wrong and maybe I should have > written #+BEGIN_EXAMPLE instead? Correct. > Though I’d still say it probably shouldn’t have failed the export?… Babel blocks are executed prior to any export process, no matter what you want to include in the output. For example, some blocks could set-up export. Therefore, a wrong Babel block always fails an export process. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-21 11:50 ` Nicolas Goaziou @ 2015-08-21 13:46 ` Ista Zahn 2015-08-21 14:20 ` Nicolas Goaziou 0 siblings, 1 reply; 14+ messages in thread From: Ista Zahn @ 2015-08-21 13:46 UTC (permalink / raw) To: JI, Xiang, emacs-orgmode Mailinglist On Fri, Aug 21, 2015 at 7:50 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > Hello, > > "JI, Xiang" <hi@xiangji.me> writes: > >> Well actually I think the error shows because of another block below >> the emacs-lisp blocks. In this header I just wrote #+BEGIN_SRC without >> any language name. Is it actually wrong and maybe I should have >> written #+BEGIN_EXAMPLE instead? > > Correct. > >> Though I’d still say it probably shouldn’t have failed the export?… > > Babel blocks are executed prior to any export process, no matter what > you want to include in the output. Unless you've restored sanity by setting org-export-babel-evaluate to nil. Personally I think this is not a good default. Source block evaluation and export are distinct actions, and I don't see why they should be linked by default. Best, Ista ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-21 13:46 ` Ista Zahn @ 2015-08-21 14:20 ` Nicolas Goaziou 2015-08-21 14:35 ` Ista Zahn 0 siblings, 1 reply; 14+ messages in thread From: Nicolas Goaziou @ 2015-08-21 14:20 UTC (permalink / raw) To: Ista Zahn; +Cc: emacs-orgmode Mailinglist, JI, Xiang Ista Zahn <istazahn@gmail.com> writes: > Unless you've restored sanity by setting org-export-babel-evaluate to > nil. Personally I think this is not a good default. Source block > evaluation and export are distinct actions, and I don't see why they > should be linked by default. Wild guess: Principle of least surprise: setting it to nil means results from Babel code are not refreshed before export, without user realizing about it. I think most users would like them to be up-to-date before export. It seems sane to me. In any case, I don't see the harm here. OP uses invalid syntax and is warned about that. I think it's a decent way to proceed. Regards, ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-21 14:20 ` Nicolas Goaziou @ 2015-08-21 14:35 ` Ista Zahn 2015-08-21 14:43 ` Andreas Leha 0 siblings, 1 reply; 14+ messages in thread From: Ista Zahn @ 2015-08-21 14:35 UTC (permalink / raw) To: Ista Zahn, JI, Xiang, emacs-orgmode Mailinglist On Fri, Aug 21, 2015 at 10:20 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > Ista Zahn <istazahn@gmail.com> writes: > >> Unless you've restored sanity by setting org-export-babel-evaluate to >> nil. Personally I think this is not a good default. Source block >> evaluation and export are distinct actions, and I don't see why they >> should be linked by default. > > Wild guess: > > Principle of least surprise: setting it to nil means results from Babel > code are not refreshed before export, without user realizing about it. > I think most users would like them to be up-to-date before export. It > seems sane to me. The problem is that if the code blocks are non-trivial it slows down the export. Changing one line of documentation and exporting re-evaluates all the code blocks, which for me often takes several minutes. The defaults work for trivial examples, but not my real-world use. Since it's easy to make it work how I want it to via org-export-babel-evaluate I don't mean to complain too much. I posted mostly to make sure the OP knows about org-export-babel-evaluate, in case disabling code block evaluation on export makes sense for them. > > In any case, I don't see the harm here. OP uses invalid syntax and is > warned about that. I think it's a decent way to proceed. Yes, I agree about that. Best, Ista > > Regards, ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-21 14:35 ` Ista Zahn @ 2015-08-21 14:43 ` Andreas Leha 2015-08-21 14:52 ` Ista Zahn 0 siblings, 1 reply; 14+ messages in thread From: Andreas Leha @ 2015-08-21 14:43 UTC (permalink / raw) To: emacs-orgmode Hi, Ista Zahn <istazahn@gmail.com> writes: > On Fri, Aug 21, 2015 at 10:20 AM, Nicolas Goaziou > <mail@nicolasgoaziou.fr> wrote: >> Ista Zahn <istazahn@gmail.com> writes: >> >>> Unless you've restored sanity by setting org-export-babel-evaluate to >>> nil. Personally I think this is not a good default. Source block >>> evaluation and export are distinct actions, and I don't see why they >>> should be linked by default. >> >> Wild guess: >> >> Principle of least surprise: setting it to nil means results from Babel >> code are not refreshed before export, without user realizing about it. >> I think most users would like them to be up-to-date before export. It >> seems sane to me. > > The problem is that if the code blocks are non-trivial it slows down > the export. Changing one line of documentation and exporting > re-evaluates all the code blocks, which for me often takes several > minutes. The defaults work for trivial examples, but not my real-world > use. Since it's easy to make it work how I want it to via > org-export-babel-evaluate I don't mean to complain too much. I posted > mostly to make sure the OP knows about org-export-babel-evaluate, in > case disabling code block evaluation on export makes sense for them. > I know that problem... Decoupling code block evaluation and export has the problem of decoupling code block evaluation and export ;-), though. If you export your document without evaluating first, how can you be sure that the resulting document is based on the latest version of the code contained in the code blocks? So, from my point of view the default is the safe option and, thus, fine. Regards, Andreas ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-21 14:43 ` Andreas Leha @ 2015-08-21 14:52 ` Ista Zahn 2015-08-21 15:04 ` Nicolas Goaziou 0 siblings, 1 reply; 14+ messages in thread From: Ista Zahn @ 2015-08-21 14:52 UTC (permalink / raw) To: Andreas Leha; +Cc: emacs-orgmode Mailinglist On Fri, Aug 21, 2015 at 10:43 AM, Andreas Leha <andreas.leha@med.uni-goettingen.de> wrote: > Hi, > > Ista Zahn <istazahn@gmail.com> writes: >> On Fri, Aug 21, 2015 at 10:20 AM, Nicolas Goaziou >> <mail@nicolasgoaziou.fr> wrote: >>> Ista Zahn <istazahn@gmail.com> writes: >>> >>>> Unless you've restored sanity by setting org-export-babel-evaluate to >>>> nil. Personally I think this is not a good default. Source block >>>> evaluation and export are distinct actions, and I don't see why they >>>> should be linked by default. >>> >>> Wild guess: >>> >>> Principle of least surprise: setting it to nil means results from Babel >>> code are not refreshed before export, without user realizing about it. >>> I think most users would like them to be up-to-date before export. It >>> seems sane to me. >> >> The problem is that if the code blocks are non-trivial it slows down >> the export. Changing one line of documentation and exporting >> re-evaluates all the code blocks, which for me often takes several >> minutes. The defaults work for trivial examples, but not my real-world >> use. Since it's easy to make it work how I want it to via >> org-export-babel-evaluate I don't mean to complain too much. I posted >> mostly to make sure the OP knows about org-export-babel-evaluate, in >> case disabling code block evaluation on export makes sense for them. >> > > I know that problem... > > Decoupling code block evaluation and export has the problem of > decoupling code block evaluation and export ;-), though. If you export > your document without evaluating first, how can you be sure that the > resulting document is based on the latest version of the code contained > in the code blocks? By calling org-babel-execute-buffer before exporting ;-) The advantage of doing it this way is that you don't have to do that if you haven't changed a code block. So, from my point of view the default is the safe > option and, thus, fine. I agree that it is safer. In my case its safer like a 10 MPH speed limit. Safe yes, but too slow! > > > Regards, > Andreas > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-21 14:52 ` Ista Zahn @ 2015-08-21 15:04 ` Nicolas Goaziou 2015-08-21 15:57 ` Ista Zahn 0 siblings, 1 reply; 14+ messages in thread From: Nicolas Goaziou @ 2015-08-21 15:04 UTC (permalink / raw) To: Ista Zahn; +Cc: Andreas Leha, emacs-orgmode Mailinglist Ista Zahn <istazahn@gmail.com> writes: > I agree that it is safer. In my case its safer like a 10 MPH speed > limit. Safe yes, but too slow! Doesn't Babel :cache property help here? Regards, ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-21 15:04 ` Nicolas Goaziou @ 2015-08-21 15:57 ` Ista Zahn 2015-08-21 20:13 ` Aaron Ecay 2015-08-21 20:19 ` Charles C. Berry 0 siblings, 2 replies; 14+ messages in thread From: Ista Zahn @ 2015-08-21 15:57 UTC (permalink / raw) To: Ista Zahn, Andreas Leha, emacs-orgmode Mailinglist On Fri, Aug 21, 2015 at 11:04 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote: > Ista Zahn <istazahn@gmail.com> writes: > >> I agree that it is safer. In my case its safer like a 10 MPH speed >> limit. Safe yes, but too slow! > > Doesn't Babel :cache property help here? It does actually, to my surprise. I have not been using :cache because the documentation says "Note that the :cache header argument will not attempt to cache results when the :session header argument is used" and since I almost always use :session I didn't expect this to work. To my surprise it does (at least with R source blocks, I haven't tested yet with others). Can I now rely on this to work even with :session? Best, Ista > > Regards, ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-21 15:57 ` Ista Zahn @ 2015-08-21 20:13 ` Aaron Ecay 2015-08-21 20:19 ` Andreas Leha 2015-08-21 20:19 ` Charles C. Berry 1 sibling, 1 reply; 14+ messages in thread From: Aaron Ecay @ 2015-08-21 20:13 UTC (permalink / raw) To: Ista Zahn Hi Ista, 2015ko abuztuak 21an, Ista Zahn-ek idatzi zuen: > > On Fri, Aug 21, 2015 at 11:04 AM, Nicolas Goaziou > <mail@nicolasgoaziou.fr> wrote: >> Ista Zahn <istazahn@gmail.com> writes: >> >>> I agree that it is safer. In my case its safer like a 10 MPH speed >>> limit. Safe yes, but too slow! >> >> Doesn't Babel :cache property help here? > > It does actually, to my surprise. I have not been using :cache because > the documentation says > > "Note that the :cache header argument will not attempt to cache > results when the :session header argument is used" > > and since I almost always use :session I didn't expect this to work. > To my surprise it does (at least with R source blocks, I haven't > tested yet with others). Can I now rely on this to work even with > :session? I think it depends on what you mean by “work.” Specifically, :cache doesn’t understand dependencies across source blocks when run in a session. So in the following document, if you edit the definition of myvar, the subsequent usage will retain the old value on subsequent exports: ========== #+begin_src R :session *foo* :cache yes myvar <- 1 myvar #+end_src #+RESULTS[8310fa64b89f36a383660d14779e88d9aa90834a]: : 1 #+begin_src R :session *foo* :cache yes myvar #+end_src #+RESULTS[5c241816868f6400ccfb54ceb6ef15dbeea16de1]: : 1 ========== There are also subtle issues related to the fact that in order to export a document, org: 1) makes a copy of the buffer 2) executes the babel blocks in this copy, destructively modifying the buffer as it goes 3) exports the result In my experience, sometimes the header arguments, and thus the hash that the cache depends on, can change. So in addition to the cache not re-evaluating when it should as above, it might needlessly re-evaluate a computationally expensive block in the middle of export. I tried to fix this about 2 years ago by getting the relevant code to not do any buffer modifications as it goes but rather first evaluate all the blocks then do all the needed modifications. However, the resultant patch was too big, and I ran out of time to work on it. Since I made that attempt, a second, unmodified copy of the buffer has been introduced to the process to help with some (nominally different but related) aspects of babel processing. This might have solved the problem, but I’m not sure. When the cache has not worked as I expected it to in the past, it’s been in the middle of actually trying to do something with org, usually under deadline pressure. Thus, I’ve adopted the conservative approach of evaluating blocks manually in all circumstances, and not trying to get caching to work. So, you might find that these problems have all gone away as a consequence of other changes. For purely R-based work, Charles Berry’s ox-ravel package <https://github.com/chasberry/orgmode-accessories/blob/master/ox-ravel.org> is a very interesting approach, since it relies on the cache feature of knitr, which is capable of automatically detecting cross-block dependencies like the example above under some circumstances <http://yihui.name/knitr/demo/cache/>. It would be interesting to see if that approach could be used to override :cache handling for ob-R, while falling back on org-babel’s less intelligent features for other languages (or in R environments that don’t have knitr available). But that’s a(nother) big project. (I’ve also never used ox-ravel in a serious project, so my impressions are just based on reading the code and documentation – which is a really excellent example of literate elisp programming). TLDR: If the standard of reliance is working as well as other cache-capable literate programming libraries for R like knitr, in my (possibly out of date) experience :cache + :session is not up to scratch. -- Aaron Ecay ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-21 20:13 ` Aaron Ecay @ 2015-08-21 20:19 ` Andreas Leha 2015-08-22 3:19 ` Charles C. Berry 0 siblings, 1 reply; 14+ messages in thread From: Andreas Leha @ 2015-08-21 20:19 UTC (permalink / raw) To: emacs-orgmode Hi, Just a small comment. [ ... discussion of :caching of evaluation results ... ] > For purely R-based work, Charles Berry’s ox-ravel package > <https://github.com/chasberry/orgmode-accessories/blob/master/ox-ravel.org> > is a very interesting approach, since it relies on the cache feature of > knitr, which is capable of automatically detecting cross-block > dependencies like the example above under some circumstances > <http://yihui.name/knitr/demo/cache/>. It would be interesting to see > if that approach could be used to override :cache handling for ob-R, > while falling back on org-babel’s less intelligent features for other > languages (or in R environments that don’t have knitr available). That would be just awesome! Regards, Andreas ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-21 20:19 ` Andreas Leha @ 2015-08-22 3:19 ` Charles C. Berry 0 siblings, 0 replies; 14+ messages in thread From: Charles C. Berry @ 2015-08-22 3:19 UTC (permalink / raw) To: Andreas Leha; +Cc: Aaron Ecay, Org-Mode mailing list [-- Attachment #1: Type: TEXT/PLAIN, Size: 2205 bytes --] On Fri, 21 Aug 2015, Andreas Leha wrote: > Hi, > > Just a small comment. > > [ ... discussion of :caching of evaluation results ... ] > >> For purely R-based work, Charles Berry’s ox-ravel package >> <https://github.com/chasberry/orgmode-accessories/blob/master/ox-ravel.org> >> is a very interesting approach, since it relies on the cache feature of >> knitr, which is capable of automatically detecting cross-block >> dependencies like the example above under some circumstances >> <http://yihui.name/knitr/demo/cache/>. It would be interesting to see >> if that approach could be used to override :cache handling for ob-R, >> while falling back on org-babel’s less intelligent features for other >> languages (or in R environments that don’t have knitr available). > > That would be just awesome! I think I understand what Aaron is suggesting, but... In ox-ravel exports, non-R src blocks get executed as usual, while R blocks get converted to `chunks' for later processing by knitr or Sweave or whatever. Anything that needs to be communicated from other languages to R via noweb `<<run-this()>>' or `:var rvar=elisp-block()' headers should work. That is, the resulting chunks will have code put into them as usual in R src block execution. (And this is useful for passing latex code to R, for example.) But when the R code is run under knitr or some other engine outside of org mode, it cannot communicate values back to src blocks using other languages. Or even other R src blocks using `:var rvar=r-src-block()', say. And it cannot use `:post' header args. I agree it would be interesting to adapt knitr or some other dependency-aware caching engine to run under babel control to allow R to push results to other src blocks. I don't know how hard it would be to make it work well. Chuck p.s. I just pushed an org mode translation of auto-dependson.Rnw from https://github.com/yihui/knitr-examples to the ravel-lang branch at https://github.com/chasberry/orgmode-accessories/blob/ravel-lang/autodep.org It illustrates automatic dependency-aware caching of R src blocks. p.p.s. I expect to move the `ravel-lang' branch to `master' soon, so I encourage users to try that branch. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` 2015-08-21 15:57 ` Ista Zahn 2015-08-21 20:13 ` Aaron Ecay @ 2015-08-21 20:19 ` Charles C. Berry 1 sibling, 0 replies; 14+ messages in thread From: Charles C. Berry @ 2015-08-21 20:19 UTC (permalink / raw) To: Ista Zahn; +Cc: Andreas Leha, emacs-orgmode Mailinglist On Fri, 21 Aug 2015, Ista Zahn wrote: > On Fri, Aug 21, 2015 at 11:04 AM, Nicolas Goaziou > <mail@nicolasgoaziou.fr> wrote: >> Ista Zahn <istazahn@gmail.com> writes: >> >>> I agree that it is safer. In my case its safer like a 10 MPH speed >>> limit. Safe yes, but too slow! >> >> Doesn't Babel :cache property help here? > > It does actually, to my surprise. I have not been using :cache because > the documentation says > > "Note that the :cache header argument will not attempt to cache > results when the :session header argument is used" > > and since I almost always use :session I didn't expect this to work. > To my surprise it does (at least with R source blocks, I haven't > tested yet with others). Can I now rely on this to work even with > :session? AFAICS, (reading `org-babel-exp-do-export') if you do not use `:results silent' it will work. Where this does not work is when `:results silent' is used. This does not execute a second time: #+BEGIN_SRC R :results output :session :cache yes date() #+END_SRC but changing to `:results silent' will run without updating the cached RESULTS (if any) every time. HTH, Chuck ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-08-22 3:19 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-08-20 9:38 "user-error: No language for src block: (unnamed)" when running `org-icalendar-combine-agenda-files` JI, Xiang 2015-08-20 9:44 ` JI, Xiang 2015-08-21 11:50 ` Nicolas Goaziou 2015-08-21 13:46 ` Ista Zahn 2015-08-21 14:20 ` Nicolas Goaziou 2015-08-21 14:35 ` Ista Zahn 2015-08-21 14:43 ` Andreas Leha 2015-08-21 14:52 ` Ista Zahn 2015-08-21 15:04 ` Nicolas Goaziou 2015-08-21 15:57 ` Ista Zahn 2015-08-21 20:13 ` Aaron Ecay 2015-08-21 20:19 ` Andreas Leha 2015-08-22 3:19 ` Charles C. Berry 2015-08-21 20:19 ` Charles C. Berry
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).