From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: new exporter Date: Sat, 09 Jun 2012 23:19:23 +0200 Message-ID: <87fwa4npyc.fsf@Rainer.invalid> References: <3C38420E-E2FA-4CAB-B3FD-9C5F8584E60A@gmail.com> <81fwadrgoo.fsf@gmail.com> <87396dzlai.fsf_-_@Rainer.invalid> <871ulqgb4t.fsf@gmail.com> <873966yjt6.fsf@Rainer.invalid> <87sje6eup9.fsf@gmail.com> <87sje4nwy1.fsf@Rainer.invalid> <87txyke2lq.fsf@gmail.com> <87k3zgnw47.fsf@Rainer.invalid> <87pq98e0b4.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:43823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdT5l-0002z9-1H for emacs-orgmode@gnu.org; Sat, 09 Jun 2012 17:21:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SdT5i-0006oQ-5Y for emacs-orgmode@gnu.org; Sat, 09 Jun 2012 17:21:04 -0400 Received: from plane.gmane.org ([80.91.229.3]:44893) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SdT5h-0006o9-US for emacs-orgmode@gnu.org; Sat, 09 Jun 2012 17:21:02 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SdT5U-0000mO-9Q for emacs-orgmode@gnu.org; Sat, 09 Jun 2012 23:20:48 +0200 Received: from pd9eb551a.dip.t-dialin.net ([217.235.85.26]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jun 2012 23:20:48 +0200 Received: from Stromeko by pd9eb551a.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jun 2012 23:20:48 +0200 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@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Nicolas Goaziou writes: > Achim Gratz writes: > >> It apparently croaks on the runtime use of cl macros and/or functions, >> but just exactly how is a mystery to me. > > org-element uses `every' twice. Since this function doesn't belong to cl > but cl-extra, could it be the source of the problem? Dunno. I have just rid org-element and org-export of all cl macros (incf, decf, loop, case, ...) and things start to compile correctly. But that is too big a hammer obviously. The use of cl macros at compile time is officially sanctioned, so the reason for this must be that you violate some assumption about their use or capture symbols used by the byte compiler. > If so, it may be worth a try to remove them from code base. I'd start with the uses of macros inside let clauses. These look really fishy to me some of those symbols look like something the byte-compiler might use itself: count, line, etc. It is clear by now that something throws the byte-compiler off really hard. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada