From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: [babel] Export problem (Wrong type argument: consp, nil) Date: Wed, 14 Sep 2011 10:52:14 +0200 Message-ID: <80y5xrld4x.fsf@somewhere.org> References: <80litzcbg1.fsf@somewhere.org> <87hb4ndj1f.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: emacs-orgmode-mXXj517/zsQ@public.gmane.org Hi Eric, Eric Schulte wrote: > "Sebastien Vauban" writes: >> If there is no value assigned to the code block... >> ... there is no an error when exporting: >> >> #+begin_src text >> Debugger entered--Lisp error: (wrong-type-argument consp nil) >> setcdr(nil "nil=x") >> #+end_src > > All variables must be given a default value, which is why it is an error > to write a code block like the following. > > #+source: circle(x) > #+begin_src python > return x*x > #+end_src > > I've just pushed up a change which provides a better error message in > this case. It works OK. Thanks a lot for that. Remark: This did correct a problem that I had with my local LOB, and which appeared a couple of months ago. I tried to find the post back, but I couldn't. At that time, you tried my example, but you couldn't reproduce it. Anyway, I now could check that it was because of this, now that the message is a lot clearer than "consp, nil". Question: Would it be possible to add the src-name in the error message? You know, in my LOB, I have so many times the same var name coming back again, that having the name of the source block would be of a great help. I tried looking into the code to see if I could do it myself, but I must admit it's still too hard for me. I have the impression many functions must be extended in order to pass the src-name down to where the error is thrown... Other thing, I tried to add a test for checking your fix never will be regressed. This is what I currently have: * Does not work :PROPERTIES: :ID: f2df5ba6-75fa-4e6b-8441-65ed84963627 :END: If there is no value assigned to the code block, a proper error should be thrown. #+source: carre(x) #+begin_src python return x*x #+end_src * Test #+begin_src emacs-lisp (ert-deftest test-org-babel/no-defaut-value-for-var () "Test that the absence of a default value for a variable does throw a proper error." (org-test-at-id "f2df5ba6-75fa-4e6b-8441-65ed84963627" (org-babel-next-src-block) (should-error (org-babel-execute-src-block)) :type 'error)) #+end_src Though, I have 2 questions: - How can I differentiate between the clean error (with a message) and the one which wasn't correctly trapped? Based on the first line of a backtrace (string comparison) or on the type of the error? In the latter case, how can I know what's the type of the current error thrown, and the one of the error before your fix? - I wonder why we need twice the =org-babel-next-src-block= call, and not only once in the =should-error= form. Thanks. Best regards, Seb -- Sebastien Vauban