possible org bug

possible org bug

[Robert Louis McIntyre]

I'm trying to upgrade my org distribution and ran into a
problem exporting java code blocks to html.

I'm using the following:

GNU Emacs 24.1.1 (i686-pc-linux-gnu, GTK+ Version 2.24.10)
of 2012-06-11 on shirley.hoetzel.info

Org-mode version 7.8.11 (release_7.8.11-217-g99ef57 @
/home/r/config/emacs/extend/org-mode/lisp/)


When I try to export certain org files with java code
blocks while using emacs in --batch mode, the export fails
with the error:

Symbol's function definition is void: nil


This only happens when using emacs in batch mode.

I've created a minimal example that demonstrates this
problem at:

 http://aurellem.org/dl/possible-org-bug.tar.bz2

there are two batch scripts, fails.sh and works.sh, the only
difference being that one uses emacs with the --batch option
while the other does not.

In order to run these scripts, you will have to change the
load-path in org-init.el file to point to your own org
distribution.

I can confirm that the "fails.sh" script works with my old
setup,

GNU Emacs 23.4.1
Org-mode version 7.7

Can anyone tell me what might be the problem with --batch
that is causing my script to fail?

sincerely,
--Robert McIntyre

Re: possible org bug

[Achim Gratz]

Robert Louis McIntyre writes:
> This only happens when using emacs in batch mode.
>
> I've created a minimal example that demonstrates this
> problem at:
>
>  http://aurellem.org/dl/possible-org-bug.tar.bz2

I'm getting the same error both in batch and in non-batch mode for Emacs
23.3 and in non-batch-mode for 24.1:

org-publish-cache-ctime-of-src: Wrong type argument: integerp, nil

The export still succeeds, but that error seems related to the fact that
you're using relative file names which are then seemingly interpreted in
the context of where the lisp file is located.  I don't know if relative
file and directory names are proper in org-publish-project-alist and
org-publish-file.  If relative should be supported, then this needs to
either be converted to absolute internally or the context for default
directory has to be carried.  Anyway, if I fix this, I will then get
another non-fatal error:

org-publish-cache-set: `org-publish-cache-set' called, but no cache
present.

Running Emacs 24.1 with toggle-debug-on-error traps in

Debugger entered--Lisp error: (void-function nil)
  nil(1 29 nil)
  c-font-lock-fontify-region(1 29 nil)
  font-lock-fontify-region(1 29 nil)
  byte-code("\212\303 ▒\304\216\305ed   #\210\306 \210\307\211+\207" [save-match-data-internal verbose font-lock-fontified match-data ((byte-code "\30\302\"\207" [save-match-data-internal set-match-data evaporate] 3)) font-lock-fontify-region font-lock-after-fontify-buffer t] 4)
  font-lock-default-fontify-buffer()
  font-lock-fontify-buffer()
  org-export-format-source-code-or-example("java" "import com.jme3.scene.Node;\n" " " 0 nil)
  org-export-replace-src-segments-and-examples()

This looks to be either a bug in font-lock or some missing setup for it
to work correctly, maybe just for Java; or java-mode (which is based on
cc-mode) tries to use facilities that aren't present in batch; or
cc-mode has a bug in version 5.32.2 that is not present in version 5.31.8.

Somebody else will have to take it from there...


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: possible org bug

[Achim Gratz]

Achim Gratz writes:
> This looks to be either a bug in font-lock or some missing setup for it
> to work correctly, maybe just for Java; or java-mode (which is based on
> cc-mode) tries to use facilities that aren't present in batch; or
> cc-mode has a bug in version 5.32.2 that is not present in version 5.31.8.
>
> Somebody else will have to take it from there...

It appears having to do with java-mode, if I associate java with another
mode for fontification (say, fundamental), export works in batch-mode.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: possible org bug

[Nick Dokos]

Achim Gratz <Stromeko@nexgo.de> wrote:

> Robert Louis McIntyre writes:
> > This only happens when using emacs in batch mode.
> >
> > I've created a minimal example that demonstrates this
> > problem at:
> >
> >  http://aurellem.org/dl/possible-org-bug.tar.bz2
> 
> I'm getting the same error both in batch and in non-batch mode for Emacs
> 23.3 and in non-batch-mode for 24.1:
> 
> org-publish-cache-ctime-of-src: Wrong type argument: integerp, nil
> 
> The export still succeeds, but that error seems related to the fact that
> you're using relative file names which are then seemingly interpreted in
> the context of where the lisp file is located.  I don't know if relative
> file and directory names are proper in org-publish-project-alist and
> org-publish-file.  If relative should be supported, then this needs to
> either be converted to absolute internally or the context for default
> directory has to be carried.  Anyway, if I fix this, I will then get
> another non-fatal error:
> 
> org-publish-cache-set: `org-publish-cache-set' called, but no cache
> present.
> 
> Running Emacs 24.1 with toggle-debug-on-error traps in
> 
> Debugger entered--Lisp error: (void-function nil)
>   nil(1 29 nil)
>   c-font-lock-fontify-region(1 29 nil)
>   font-lock-fontify-region(1 29 nil)
>   byte-code("..." [save-match-data-internal verbose font-lock-fontified match-data ((byte-code "..." [save-match-data-internal set-match-data evaporate] 3)) font-lock-fontify-region font-lock-after-fontify-buffer t] 4)
>   font-lock-default-fontify-buffer()
>   font-lock-fontify-buffer()
>   org-export-format-source-code-or-example("java" "import com.jme3.scene.Node;\n" " " 0 nil)
>   org-export-replace-src-segments-and-examples()
> 
> This looks to be either a bug in font-lock or some missing setup for it
> to work correctly, maybe just for Java; or java-mode (which is based on
> cc-mode) tries to use facilities that aren't present in batch; or
> cc-mode has a bug in version 5.32.2 that is not present in version 5.31.8.
> 
> Somebody else will have to take it from there...
> 

Re: the relative vs. absolute pathnames - David Maus had fixed a problem
with symlinks but was trying to avoid carrying the default directory
context. See this thread:

    http://thread.gmane.org/gmane.emacs.orgmode/40645

I just wanted to make sure that anybody who takes a look at this, keeps
in mind the symlink case(s) as well.

But I also wanted to add a plug for the exemplary bug report that the OP
put together: if all bug reports were as complete as this one, life
would be much easier. I usually complain about bad bug reports, so this
was my chance to praise a good one: thanks!

Nick

PS. I had got to the cache problem (but not as far as the font-lock
problem that Achim traced it to), ran out of time, wanted to get back to
it but never got the chance. I might be able to take another look at it
this weekend, but if anybody beats me to it, I will *not* complain...

Re: possible org bug

[Bastien]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

Hi Nick,

Nick Dokos <nicholas.dokos@hp.com> writes:

> Re: the relative vs. absolute pathnames - David Maus had fixed a problem
> with symlinks but was trying to avoid carrying the default directory
> context. See this thread:
>
>     http://thread.gmane.org/gmane.emacs.orgmode/40645
>
> I just wanted to make sure that anybody who takes a look at this, keeps
> in mind the symlink case(s) as well.
>
> But I also wanted to add a plug for the exemplary bug report that the OP
> put together: if all bug reports were as complete as this one, life
> would be much easier. I usually complain about bad bug reports, so this
> was my chance to praise a good one: thanks!
>
> Nick
>
> PS. I had got to the cache problem (but not as far as the font-lock
> problem that Achim traced it to), ran out of time, wanted to get back to
> it but never got the chance. I might be able to take another look at it
> this weekend, but if anybody beats me to it, I will *not* complain...

Here is another chance.  :)

Please test the attached patch and see if this fixes the issue.

Thanks!


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-publish.el-Fix-problem-with-org-publish-cache-ct.patch --]
[-- Type: text/x-patch, Size: 5184 bytes --]

From 55f1cf816d65b1c98044ae82a42da84b5613c5bd Mon Sep 17 00:00:00 2001
From: Bastien Guerry <bzg@altern.org>
Date: Fri, 10 Aug 2012 13:04:55 +0200
Subject: [PATCH] org-publish.el: Fix problem with
 `org-publish-cache-ctime-of-src' not expanding from the
 correct directory

* org-publish.el (org-publish-needed-p)
(org-publish-update-timestamp, org-publish-file)
(org-publish-cache-file-needs-publishing): New argument
`base-dir'.
(org-publish-cache-ctime-of-src): Use the new argument to make
sure we find the file according to :base-directory.
---
 lisp/org-publish.el |   28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/lisp/org-publish.el b/lisp/org-publish.el
index cb496ff..3225495 100644
--- a/lisp/org-publish.el
+++ b/lisp/org-publish.el
@@ -315,7 +315,7 @@ You could use brackets to delimit on what part the link will be.
 			 (format "%s" (or pub-func ""))))
   (concat "X" (if (fboundp 'sha1) (sha1 filename) (md5 filename))))
 
-(defun org-publish-needed-p (filename &optional pub-dir pub-func true-pub-dir)
+(defun org-publish-needed-p (filename &optional pub-dir pub-func true-pub-dir base-dir)
   "Return t if FILENAME should be published in PUB-DIR using PUB-FUNC.
 TRUE-PUB-DIR is where the file will truly end up.  Currently we are not using
 this - maybe it can eventually be used to check if the file is present at
@@ -325,7 +325,7 @@ function can still decide about that independently."
   (let ((rtn
 	 (if org-publish-use-timestamps-flag
 	     (org-publish-cache-file-needs-publishing
-	      filename pub-dir pub-func)
+	      filename pub-dir pub-func base-dir)
 	   ;; don't use timestamps, always return t
 	   t)))
     (if rtn
@@ -334,11 +334,11 @@ function can still decide about that independently."
 	(message   "Skipping unmodified file %s" filename)))
     rtn))
 
-(defun org-publish-update-timestamp (filename &optional pub-dir pub-func)
+(defun org-publish-update-timestamp (filename &optional pub-dir pub-func base-dir)
   "Update publishing timestamp for file FILENAME.
 If there is no timestamp, create one."
   (let ((key (org-publish-timestamp-filename filename pub-dir pub-func))
-	(stamp (org-publish-cache-ctime-of-src filename)))
+	(stamp (org-publish-cache-ctime-of-src filename base-dir)))
     (org-publish-cache-set key stamp)))
 
 (defun org-publish-remove-all-timestamps ()
@@ -705,15 +705,14 @@ See `org-publish-projects'."
     (if (listp publishing-function)
 	;; allow chain of publishing functions
 	(mapc (lambda (f)
-		(when (org-publish-needed-p filename pub-dir f tmp-pub-dir)
+		(when (org-publish-needed-p filename pub-dir f tmp-pub-dir base-dir)
 		  (funcall f project-plist filename tmp-pub-dir)
-		  (org-publish-update-timestamp filename pub-dir f)))
+		  (org-publish-update-timestamp filename pub-dir f base-dir)))
 	      publishing-function)
-      (when (org-publish-needed-p filename pub-dir publishing-function
-				  tmp-pub-dir)
+      (when (org-publish-needed-p filename pub-dir publishing-function tmp-pub-dir base-dir)
 	(funcall publishing-function project-plist filename tmp-pub-dir)
 	(org-publish-update-timestamp
-	 filename pub-dir publishing-function)))
+	 filename pub-dir publishing-function base-dir)))
     (unless no-cache (org-publish-write-cache-file))))
 
 (defun org-publish-projects (projects)
@@ -1103,7 +1102,7 @@ If FREE-CACHE, empty the cache."
       (clrhash org-publish-cache))
   (setq org-publish-cache nil))
 
-(defun org-publish-cache-file-needs-publishing (filename &optional pub-dir pub-func)
+(defun org-publish-cache-file-needs-publishing (filename &optional pub-dir pub-func base-dir)
   "Check the timestamp of the last publishing of FILENAME.
 Return `t', if the file needs publishing.  The function also
 checks if any included files have been more recently published,
@@ -1123,12 +1122,12 @@ so that the file including them will be republished as well."
 	(while (re-search-forward "^#\\+include:[ \t]+\"\\([^\t\n\r\"]*\\)\"[ \t]*.*$" nil t)
 	  (let* ((included-file (expand-file-name (match-string 1))))
 	    (add-to-list 'included-files-ctime
-			 (org-publish-cache-ctime-of-src included-file) t))))
+			 (org-publish-cache-ctime-of-src included-file base-dir) t))))
       ;; FIXME don't kill current buffer
       (unless visiting (kill-buffer buf)))
     (if (null pstamp)
 	t
-      (let ((ctime (org-publish-cache-ctime-of-src filename)))
+      (let ((ctime (org-publish-cache-ctime-of-src filename base-dir)))
 	(or (< pstamp ctime)
 	    (when included-files-ctime
 	      (not (null (delq nil (mapcar (lambda(ct) (< ctime ct))
@@ -1183,9 +1182,10 @@ Returns value on success, else nil."
       (error "`org-publish-cache-set' called, but no cache present"))
   (puthash key value org-publish-cache))
 
-(defun org-publish-cache-ctime-of-src (f)
+(defun org-publish-cache-ctime-of-src (f base-dir)
   "Get the FILENAME ctime as an integer."
-  (let ((attr (file-attributes (expand-file-name (or (file-symlink-p f) f)))))
+  (let ((attr (file-attributes
+	       (expand-file-name (or (file-symlink-p f) f) base-dir))))
     (+ (lsh (car (nth 5 attr)) 16)
        (cadr (nth 5 attr)))))
 
-- 
1.7.10.2


[-- Attachment #3: Type: text/plain, Size: 14 bytes --]


-- 
 Bastien

Re: possible org bug

[Bastien]

Bastien <bzg@gnu.org> writes:

> Please test the attached patch and see if this fixes the issue.

I've now pushed this patch.

Please report any issue you might have with org-publish.

Thanks,

-- 
 Bastien