emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: possible org bug
Date: Wed, 25 Jul 2012 20:17:46 +0200	[thread overview]
Message-ID: <878ve7d7sl.fsf@Rainer.invalid> (raw)
In-Reply-To: 87d33rzecj.fsf@argentum.i-did-not-set--mail-host-address--so-tickle-me

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

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)
  org-export-format-source-code-or-example("java" "import com.jme3.scene.Node;\n" " " 0 nil)

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...

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

Factory and User Sound Singles for Waldorf rackAttack:

  reply	other threads:[~2012-07-25 18:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-19 20:27 possible org bug Robert Louis McIntyre
2012-07-25 18:17 ` Achim Gratz [this message]
2012-07-25 18:32   ` Achim Gratz
2012-07-25 19:00   ` Nick Dokos
2012-08-10 11:06     ` Bastien
2012-08-11 16:58       ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878ve7d7sl.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


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).