From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: on the fragility of export to ODT Date: Tue, 17 Feb 2015 22:04:45 +0100 Message-ID: <87lhjwuu4y.fsf@nicolasgoaziou.fr> References: <87r3tp3gv0.fsf@ucl.ac.uk> <87wq3hhalm.fsf@nicolasgoaziou.fr> <87a90c9zsg.fsf@delle7240.chemeng.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNpIz-0007Ph-1g for emacs-orgmode@gnu.org; Tue, 17 Feb 2015 16:03:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNpIu-0008A6-Jx for emacs-orgmode@gnu.org; Tue, 17 Feb 2015 16:03:40 -0500 Received: from relay3-d.mail.gandi.net ([2001:4b98:c:538::195]:40074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNpIu-00089H-EH for emacs-orgmode@gnu.org; Tue, 17 Feb 2015 16:03:36 -0500 Received: from mfilter13-d.gandi.net (mfilter13-d.gandi.net [217.70.178.141]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 69750A80BE for ; Tue, 17 Feb 2015 22:03:35 +0100 (CET) Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter13-d.gandi.net (mfilter13-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 9jFYzgIKKGgn for ; Tue, 17 Feb 2015 22:03:34 +0100 (CET) Received: from selenimh (unknown [91.224.148.150]) (Authenticated sender: mail@nicolasgoaziou.fr) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 00214A80CE for ; Tue, 17 Feb 2015 22:03:33 +0100 (CET) In-Reply-To: <87a90c9zsg.fsf@delle7240.chemeng.ucl.ac.uk> (Eric S. Fraga's message of "Tue, 17 Feb 2015 18:08:15 +0000") 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 Eric S Fraga writes: > I have many internal references; in this document, all are to named > tables and figures. The error comes from a figure, not a table, if that helps. > I have tried but haven't managed to track down which one is causing > problems in this case. > > I have tried extracting various bits into smaller org files but then the > problems disappear... :( > > Part of the problem, I think (but please correct me if I'm wrong), is > that the positions indicated in the error messages are in the buffer > being exported after a certain amount of processing (including, I would > imagine, babel) and so it's difficult to find the actual location of the > problem. > > If this is indeed the case, is there any way to retain the buffer that > is being processed at the point the error occurs? You're right, buffer positions mean nothing here. However, there's a simpler solution. In- "ox-odt.el", function `org-odt-link--infer-description', line 2655 (but it depends on Org version), there is (t (error "FIXME: Resolve %s" destination)) Replace it with (t (error "FIXME: Resolve %s" (org-element-interpret-data destination)))) reload Org then trigger the error. The backtrace should be more interesting. Regards,